iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 701: Specify a lower bound for the nesting level (#3048)

This commit is contained in:
Pablo Galindo Salgado 2023-03-10 16:38:58 +00:00 committed by GitHub
parent a44796ee65
commit d318dc8329
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
pep-0701.rst
View File

@ -9,6 +9,7 @@ Type: Standards Track
Content-Type: text/x-rst Content-Type: text/x-rst
Created: 15-Nov-2022 Created: 15-Nov-2022
Python-Version: 3.12 Python-Version: 3.12
Post-History: `19-Dec-2022 <https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046>`__,
Abstract Abstract
@ -187,7 +188,7 @@ f-string literals (as well as the Python language in general).
>>> f"{f"{f"{f"{f"{f"{1+1}"}"}"}"}"}" >>> f"{f"{f"{f"{f"{f"{1+1}"}"}"}"}"}"
'2' '2'
Although this is just a consequence of allowing arbitrary expressions, the Although this is just a consequence of allowing arbitrary expressions, the
authors of this PEP do not believe that this is a fundamental benefit and we authors of this PEP do not believe that this is a fundamental benefit and we
have decided that the language specification will not explicitly mandate that have decided that the language specification will not explicitly mandate that
@ -225,9 +226,12 @@ for details on the syntax):
The new tokens (``FSTRING_START``, ``FSTRING_MIDDLE``, ``FSTRING_END``) are defined The new tokens (``FSTRING_START``, ``FSTRING_MIDDLE``, ``FSTRING_END``) are defined
:ref:`later in this document <701-new-tokens>`. :ref:`later in this document <701-new-tokens>`.
This PEP leaves up to the implementation the level of f-string nesting allowed. This PEP leaves up to the implementation the level of f-string nesting allowed but
This means that limiting nesting is **not part of the language specification** **specifies a lower bound of 5 levels of nesting**. This is to ensure that users can
but also the language specification **doesn't mandate arbitrary nesting**. have a reasonable expectation of being able to nest f-strings with "reasonable" depth.
This PEP implies that limiting nesting is **not part of the language
specification** but also the language specification **doesn't mandate arbitrary
nesting**.
The new grammar will preserve the Abstract Syntax Tree (AST) of the current The new grammar will preserve the Abstract Syntax Tree (AST) of the current
implementation. This means that no semantic changes will be introduced by this implementation. This means that no semantic changes will be introduced by this
@ -436,7 +440,7 @@ Some of these objections include:
strings are fully delimited by two consecutive pairs of the same kind of quote, which by itself is a very simple rule. strings are fully delimited by two consecutive pairs of the same kind of quote, which by itself is a very simple rule.
One of the reasons quote reuse may be harder for humans to parse, leading to less readable One of the reasons quote reuse may be harder for humans to parse, leading to less readable
code, is that the quote character is the same for both start and code, is that the quote character is the same for both start and
end (as opposed to other delimiters). end (as opposed to other delimiters).
* Some users have raised concerns that quote reuse may break some lexer and syntax highlighting tools that rely * Some users have raised concerns that quote reuse may break some lexer and syntax highlighting tools that rely
on simple mechanisms to detect strings and f-strings, such as regular expressions or simple delimiter on simple mechanisms to detect strings and f-strings, such as regular expressions or simple delimiter
@ -450,7 +454,7 @@ Here are some of the arguments in favour:
* Many languages that allow similar syntactic constructs (normally called "string interpolation") allow quote * Many languages that allow similar syntactic constructs (normally called "string interpolation") allow quote
reuse and arbitrary nesting. These languages include JavaScript, Ruby, C#, Bash, Swift and many others. reuse and arbitrary nesting. These languages include JavaScript, Ruby, C#, Bash, Swift and many others.
The fact that many languages allow quote reuse can be a compelling argument in favour of allowing it in Python. This The fact that many languages allow quote reuse can be a compelling argument in favour of allowing it in Python. This
is because it will make the language more familiar to users coming from other languages. is because it will make the language more familiar to users coming from other languages.
* As many other popular languages allow quote reuse in string interpolation constructs, this means that editors * As many other popular languages allow quote reuse in string interpolation constructs, this means that editors
that support syntax highlighting for these languages will already have the necessary tools to support syntax that support syntax highlighting for these languages will already have the necessary tools to support syntax
@ -518,7 +522,7 @@ now allowed: as an arbitrary Python string can contain any possible choice of
quotes, so can any f-string expression. Additionally there is no need to clarify quotes, so can any f-string expression. Additionally there is no need to clarify
that certain things are not allowed in the expression part because of that certain things are not allowed in the expression part because of
implementation restrictions such as comments, new line characters or implementation restrictions such as comments, new line characters or
backslashes. backslashes.
The only "surprising" difference is that as f-strings allow specifying a The only "surprising" difference is that as f-strings allow specifying a
format, expressions that allow a ``:`` character at the top level still need to be format, expressions that allow a ``:`` character at the top level still need to be
@ -554,7 +558,7 @@ Rejected Ideas
>>> f'Useless use of lambdas: { lambda x: x*2 }' >>> f'Useless use of lambdas: { lambda x: x*2 }'
SyntaxError: unexpected EOF while parsing SyntaxError: unexpected EOF while parsing
The reason is that this would this will introduce a considerable amount of The reason is that this would this will introduce a considerable amount of
complexity for no real benefit. This is due to the fact that the ``:`` character complexity for no real benefit. This is due to the fact that the ``:`` character
normally separates the f-string format specification. This format specification normally separates the f-string format specification. This format specification