[Python-checkins] python/nondist/peps pep-0292.txt,1.12,1.13

bwarsaw at users.sourceforge.net bwarsaw at users.sourceforge.net
Wed Aug 25 04:02:11 CEST 2004


Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20928

Modified Files:
	pep-0292.txt 
Log Message:
The open issues are resolved.


Index: pep-0292.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0292.txt,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -r1.12 -r1.13
--- pep-0292.txt	23 Aug 2004 03:31:45 -0000	1.12
+++ pep-0292.txt	25 Aug 2004 02:02:08 -0000	1.13
@@ -62,9 +62,10 @@
        not part of the placeholder, e.g. "${noun}ification".
 
     If the $ character appears at the end of the line, or is followed
-    by any other character than those described above, it is treated
-    as if it had been escaped, appearing in the resulting string
-    unchanged.  NOTE: see open issues below.
+    by any other character than those described above, a ValueError
+    will be raised at interpolation time.  Values in the mapping will
+    be converted to Unicode strings by calling the built-in unicode()
+    function, using its default arguments.
 
     No other characters have special meaning, however it is possible
     to derive from the Template class to define different rules for
@@ -167,57 +168,6 @@
     proposal, include unit tests and documentation changes.
 
 
-Open Issues
-
-    - Should the Template and SafeTemplate classes convert mapping
-      values to strings (or unicodes)?  I.e. what should this code do:
-
-      >>> from string import Template
-      >>> Template('The cost was $amount euros') % {'amount': 7}
-
-      Should this raise an exception such as TypeError, or should this
-      return the string 'The cose was 7 euros'?
-
-      Proposed resolution: no automatic stringification.
-
-    - The pattern for placeholders in the Template and SafeTemplate
-      classes matches Python identifiers.  Some people want to match
-      Python attribute paths, e.g. "$os.path.sep".  This can be useful
-      in some applications, however note that it is up to the
-      interpolation mapping to provide namespace lookup for the
-      attribute paths.
-
-      Should we include AttributeTemplate and SafeAttributeTemplate in
-      the standard library?  What about more complex patterns such as
-      Python expressions?
-
-      Proposed resolution: No, we don't include them for now.  Such
-      classes are easily derived, and besides, we're not proposing to
-      include any interpolation mappings, and without such a
-      specialized mapping, a pattern matching attribute paths or
-      expressions aren't useful.
-
-    - Where does the Template and SafeTemplate classes live?  Some
-      people have suggested creating a stringtools or stringlib module
-      to house these two classes.  The PEP author has proposed a
-      re-organization of the existing string module, turning it into a
-      string package.
-
-      Proposed resolution: There seems little consensus around either
-      suggestion, and since the classes are just a few lines of
-      Python, I propose no string module re-organization, but to add
-      these two classes to string.py.
-
-    - Should the $-placeholder rules be more strict?  Specifically,
-      objections have been raised about 'magically' escaping $'s at
-      the end of strings, or in strings like '$100'.  The suggestion
-      was that we add another matching group which matches bare $'s,
-      raising a ValueError if we find such a match.
-
-      Proposed resolution: There seems to be consensus for strictness
-      on the grounds of explicit is better than implicit.
-
-
 References
 
     [1] String Formatting Operations



More information about the Python-checkins mailing list