From 1ac7cab2853980e9db9b3d892f9dffaff6a6edf3 Mon Sep 17 00:00:00 2001 From: Barry Warsaw Date: Fri, 12 Jul 2002 23:21:08 +0000 Subject: [PATCH] Added a section containing Guido's list of real issues. --- pep-0292.txt | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/pep-0292.txt b/pep-0292.txt index d946ff1d2..cb4ffc501 100644 --- a/pep-0292.txt +++ b/pep-0292.txt @@ -301,6 +301,31 @@ Comparison to PEP 215 .sub() allows at least as much power with no loss of readability. +BDFL Weathervane + + Guido lays out[3] what he feels are the real issues that need to + be fleshed out in this PEP: + + - Compile-time vs. run-time parsing. I've become convinced that + the compiler should do the parsing: this is the only way to make + access to variables in nested scopes work, avoids security + issues, and makes it easier to diagnose errors (e.g. in + PyChecker). + + - How to support translation. Here the template must be replaced + at run-time, but it is still desirable that the collection of + available names is known at compile time (to avoid the security + issues). + + - Optional formatting specifiers. I agree with Lalo that these + should not be part of the interpolation syntax but need to be + dealt with at a different level. I think these are only + relevant for numeric data. Funny, there's still a + (now-deprecated) module fpformat.py that supports arbitrary + floating point formatting, and string.zfill() supports a bit of + integer formatting. + + References [1] String Formatting Operations @@ -309,6 +334,9 @@ References [2] Identifiers and Keywords http://www.python.org/doc/current/ref/identifiers.html + [3] Guido's python-dev posting from 21-Jul-2002 + http://mail.python.org/pipermail/python-dev/2002-July/026397.html + Copyright