Bunch of updates (not sure I got them all, the thread was looonggg. ;)

pep-0292.txt

@@ -36,7 +36,13 @@ Rationale
     `s' in "%(name)s".
 
     In addition, the rules for what can follow a % sign are fairly
-    complex, while the usual application rarely needs such complexity.
+    complex, while the usual application rarely needs such
+    complexity.  Also error prone is the right-hand side of the %
+    operator: e.g. singleton tuples.
+
+    Most scripts need to do some string interpolation, but most of
+    those use simple `stringification' formats, i.e. %s or %(name)s
+    This form should be made simpler and less error prone.
 
 
 A Simpler Proposal
@@ -246,6 +252,22 @@ Open Issues, Comments, and Suggestions
        are doing simple text processing in some kind of
        embedded-Python environment."
 
+     - Should we take a cue from the `make' program and allow $(name)
+       as an alternative (or instead of) ${name}?
+
+     - Should we require a dictionary to the .sub() method?  Some
+       people feel that it could be a security risk allowing implicit
+       access to globals/locals, even with the proper admonitions in
+       the documentation.  In that case, a new built-in would be
+       necessary (because none of globals(), locals(), or vars() does
+       the right the w.r.t. nested scopes, etc.).  Chirstian Tismer
+       has suggested allvars().  Perhaps allvars() should be a method
+       on a frame object (too?)?
+
+     - It has been suggested that using $ at all violates TOOWTDI.
+       Some other suggestions include using the % sign in the
+       following way: %{name}
+
 
 Comparison to PEP 215