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: Proofreading / copy editing (#2935)

This commit is contained in:
Dane Hillard 2022-12-20 06:58:54 -05:00 committed by GitHub
parent 09032faf9b
commit f68b3c1898
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
pep-0701.rst
View File

@ -73,7 +73,7 @@ Some of these limitations (collected originally by :pep:`536`) are:
$"{$"{1+2}"}"
These limitations serve no purpose from a language user perspective and
can be lifted by giving f-literals a regular grammar without exceptions
can be lifted by giving f-string literals a regular grammar without exceptions
and implementing it using dedicated parse code.
The other issue that f-strings have is that the current implementation in
@ -144,7 +144,7 @@ f-string literals (as well as the Python language in general).
>>> f"{f"{f"infinite"}"}" + " " + f"{f"nesting!!!"}"
This choice not only allows for a more consistent and predictable behavior of what can be
placed in f-strings but provides an intuitive way to manimulate string literals in a
placed in f-strings but provides an intuitive way to manipulate string literals in a
more flexible way without to having to fight the limitations of the implementation.
#. Another issue that has felt unintuitive to most is the lack of support for backslashes
@ -251,7 +251,7 @@ token contents. However, incorporating this feature into a given parser
implementation requires the lexer to keep track of the raw string contents of
the expression part of the f-string and make them available to the parser when
the parse tree is constructed for f-string nodes. A pure "untokenization" is not
enough because as specified currently, f-string debugging preserve whitespace,
enough because as specified currently, f-string debug expressions preserve whitespace in the expression,
including spaces after the ``{`` and the ``=`` characters. This means that the
raw string contents of the expression part of the f-string must be kept intact
and not just the associated tokens.
@ -311,16 +311,16 @@ while ``f"""some words"""`` will be tokenized simply as::
Consequences of the new grammar
-------------------------------
All restrictions mentioned in the PEP are lifted from f-literals, as explained below:
All restrictions mentioned in the PEP are lifted from f-string literals, as explained below:
* Expression portions may now contain strings delimited with the same kind of
quote that is used to delimit the f-literal.
quote that is used to delimit the f-string literal.
* Backslashes may now appear within expressions just like anywhere else in
Python code. In case of strings nested within f-literals, escape sequences are
Python code. In case of strings nested within f-string literals, escape sequences are
expanded when the innermost string is evaluated.
* Comments, using the ``#`` character, are possible only in multi-line f-literals,
* Comments, using the ``#`` character, are possible only in multi-line f-string literals,
since comments are terminated by the end of the line (which makes closing a
single-line f-literal impossible)
single-line f-string literal impossible)
Backwards Compatibility
=======================