From d318dc8329acb6008f156f52eb60620265154a59 Mon Sep 17 00:00:00 2001 From: Pablo Galindo Salgado Date: Fri, 10 Mar 2023 16:38:58 +0000 Subject: [PATCH] PEP 701: Specify a lower bound for the nesting level (#3048) --- pep-0701.rst | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/pep-0701.rst b/pep-0701.rst index ce33b5ec2..a292c331e 100644 --- a/pep-0701.rst +++ b/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 `__, 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