Added a section containing Guido's list of real issues.

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