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

pep-0701.rst

@@ -9,6 +9,7 @@ Type: Standards Track
 Content-Type: text/x-rst
 Created: 15-Nov-2022
 Python-Version: 3.12
+Post-History: `19-Dec-2022 <https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046>`__,
 
 
 Abstract
@@ -187,7 +188,7 @@ f-string literals (as well as the Python language in general).
 
     >>> f"{f"{f"{f"{f"{f"{1+1}"}"}"}"}"}"
     '2'
-   
+
    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
    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
 :ref:`later in this document <701-new-tokens>`.
 
-This PEP leaves up to the implementation the level of f-string nesting allowed.
-This means that limiting nesting is **not part of the language specification**
-but also the language specification **doesn't mandate arbitrary nesting**. 
+This PEP leaves up to the implementation the level of f-string nesting allowed but
+**specifies a lower bound of 5 levels of nesting**. This is to ensure that users can
+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
 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.
   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
-  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
   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
   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
-  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
   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
 that certain things are not allowed in the expression part because of
 implementation restrictions such as comments, new line characters or
-backslashes. 
+backslashes.
 
 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
@@ -554,7 +558,7 @@ Rejected Ideas
 
     >>> f'Useless use of lambdas: { lambda x: x*2 }'
     SyntaxError: unexpected EOF while parsing
-   
+
    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
    normally separates the f-string format specification. This format specification