[Python-checkins] peps: PEP 501: named field attrs, update keyword arg discussion

nick.coghlan python-checkins at python.org
Sun Aug 23 04:39:05 CEST 2015 

https://hg.python.org/peps/rev/42e6bc86ca5e
changeset:   5978:42e6bc86ca5e
user:        Nick Coghlan <ncoghlan at gmail.com>
date:        Sun Aug 23 07:34:57 2015 +1000
summary:
  PEP 501: named field attrs, update keyword arg discussion

files:
  pep-0501.txt |  85 +++++++++++++++++++++++++--------------
  1 files changed, 55 insertions(+), 30 deletions(-)


diff --git a/pep-0501.txt b/pep-0501.txt
--- a/pep-0501.txt
+++ b/pep-0501.txt
@@ -43,6 +43,7 @@
     myquery = sql$"SELECT $column FROM $table;"
     mycommand = sh$"cat $filename"
     mypage = html$"<html><body>${response.body}</body></html>"
+    callable = defer$ "$x + $y"
 
 Proposal
 ========
@@ -101,11 +102,11 @@
 expressions into Python, when we already have 3 (``str.format``,
 ``bytes.__mod__`` and ``string.Template``)
 
-This PEP proposes to handle the latter issue by always specifying an explicit
-interpolator for interpolation operations, and the former by adopting the
+This PEP proposes to handle the former issue by always specifying an explicit
+interpolator for interpolation operations, and the latter by adopting the
 ``string.Template`` substitution syntax defined in PEP 292.
 
-The interpolation syntax devised for PEP 292 is deliberately simple so that the
+The substitution syntax devised for PEP 292 is deliberately simple so that the
 template strings can be extracted into an i18n message catalog, and passed to
 translators who may not themselves be developers. For these use cases, it is
 important that the interpolation syntax be as simple as possible, as the
@@ -120,7 +121,7 @@
 tools the option of rejecting usage of that more advanced syntax at runtime,
 rather than categorically rejecting it at compile time. The proposed permitted
 expressions, conversion specifiers, and format specifiers inside ``${ref}`` are
-exactly as defined in PEP 498.
+exactly as defined for ``{ref}`` substituion in PEP 498.
 
 The specific proposal in this PEP is also deliberately close in both syntax
 and semantics to the general purpose interpolation syntax introduced to
@@ -156,7 +157,7 @@
 
 These components are then organised into a tuple of tuples, and passed to the
 ``__interpolate__`` method of the interpolator identified by the given
-name::
+name along with the runtime values of any expressions to be interpolated::
 
     DOTTED_NAME.__interpolate__(TEMPLATE_STRING,
                                 <parsed_fields>,
@@ -172,15 +173,29 @@
 * the substitution conversion specifier (as defined by str.format)
 * the substitution format specifier (as defined by str.format)
 
-If a given substition field has no leading literal section, format specifier
-or conversion specifier, then the corresponding elements in the tuple are the
+This field ordering is defined such that reading the parsed field tuples from
+left to right will have all the subcomponents displayed in the same order as
+they appear in the original template string.
+
+For ease of access the sequence elements will be available as attributes in
+addition to being available by position:
+
+* ``leading_text``
+* ``field_position``
+* ``expression``
+* ``conversion``
+* ``format``
+
+The expression text is simply the text of the substitution expression, as it
+appeared in the original string, but without the leading and/or surrounding
+expression markers. The conversion specifier and format specifier are separated
+from the substition expression by ``!`` and ``:`` as defined for ``str.format``.
+
+If a given substition field has no leading literal section, coversion specifier
+or format specifier, then the corresponding elements in the tuple are the
 empty string. If the final part of the string has no trailing substitution
-field, then the field number, format specifier
-and conversion specifier will all be ``None``.
-
-The expression text is simply the text of each interpolated expression, as it
-appeared in the original string, but without the leading and/or surrounding
-expression markers.
+field, then the field position, field expression, conversion specifier and
+format specifier will all be ``None``.
 
 The substitution field values tuple is created by evaluating the interpolated
 expressions in the exact runtime context where the interpolation expression
@@ -360,9 +375,10 @@
 
 And would could then be invoked as::
 
+    # _ = i18n at top of module or injected into the builtins module
     print(_$"This is a $translated $message")
 
-Any actual implementation would need to address other issues (most notably
+Any actual i18n implementation would need to address other issues (most notably
 message catalog extraction), but this gives the general idea of what might be
 possible.
 
@@ -406,6 +422,28 @@
 Refer to PEP 498 for additional discussion, as several of the points there
 also apply to this PEP.
 
+Using call syntax to support keyword-only parameters
+----------------------------------------------------
+
+The logging examples raise the question of whether or not it may be desirable
+to allow interpolators to accept arbitrary keyword arguments, and allow folks
+to write things like::
+
+    logging.critical$"Error: $error; Details: $data"(exc_info=True)
+
+in order to pass additional keyword only arguments to the interpolator.
+
+With the current PEP, such code would attempt to call the result of the
+interpolation operation. If interpolation keyword support was added, then
+calling the result of an interpolation operation directly would require
+parentheses for disambiguation::
+
+    (defer$ "$x + $y")()
+
+("defer" here would be an interpolator that compiled the supplied string as
+a piece of Python code with eagerly bound references to the containing
+namespace)
+
 Determining relative precedence
 -------------------------------
 
@@ -457,22 +495,9 @@
 has other differences (like including both the field position number *and* the
 text of the expression).
 
-Using call syntax to support keyword-only parameters
-----------------------------------------------------
-
-The logging examples could potentially be better written as::
-
-    !logging.debug("Event: $event; Details: $data")
-    !logging.critical("Error: $error; Details: $data")
-
-The key benefit this would provide is access to keyword arguments, so you
-could write:
-
-    !logging.critical("Error: $error; Details: $data", exc_info=True)
-
-In this version, an interpolation expression would largely be syntactically
-equivalent to a normal function call, except that it would be restricted to
-accepting a single string literal as its sole position argument.
+This PEP also makes the parsed field attributes available by name, so it's
+possible to write interpolators without caring about the precise field order
+at all.
 
 References
 ==========

-- 
Repository URL: https://hg.python.org/peps

More information about the Python-checkins mailing list