[Barry Warsaw]

Attached is the latest version of PEP 292, which describes simpler string substitutions. This PEP is slated for inclusion in Python 2.4 and will likely be checked in before the next alpha release.

Hi, people. The PEP was sent to python-list, but I'm replying to python-dev. As the PEP is "slated for inclusion in Python 2.4", I presume it was sent for information purposes, and not at all as a call for discussion or feedback. Nevertheless, here at least, I dare a few comments. :-) I like the avenue taken by this PEP, especially about _not_ altering Python syntax, and caring about internationalisation issues. Yet I'm rather -0.1 on the whole thing, considering that implementation might not fully meet its official goal, which is making string less error-prone, as per quote 1) below. However, consider quote 2) and 3): Quote 1)

This PEP is "simpler" in two respects:

1. Python's current string substitution feature (i.e. %-substitution) is complicated and error prone.

Quote 2)

Open Issues

>>> from string import Template >>> Template('The cost was $amount euros') % {'amount': 7}

Proposed resolution: no automatic stringification.

Quote 3)

- Should the $-placeholder rules be more strict?

Proposed resolution: There seems to be consensus for strictness on the grounds of explicit is better than implicit.

These two quotes let me think that people will often forget to stringify numbers and various other value types, or to escape a few isolated `$'. This is a lost compared to the current `%(key)s' which is much more forgiving and helpful, in that it always stringify the value. So, the feature implemented by this PEP will _also_ be a bit complicated and error prone. We might not be gaining much overall, and yet, we loose the simplicity of having only one main interpolation mechanism. Of course, the PEP is accepted, and my opinion has no effect, so I'll stick on one or two details. I have the fuzzy feeling that one unstated, but important goal of the PEP is to find some way to push `$' forward for stringification in Python. The whole PEP might even be a stunt or justification for this unstated goal. However, as this goal is well reached, it might somehow have contributed to the PEP acceptation and counterweight the deficiency stated in the preceding paragraph. If my feeling is right, then the PEP should clearly explicit this goal, it will make the PEP stronger.

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.

I witnessed a serious effort in this developers' group to "empty" the `string' module in favour of string methods. That effort has been abandoned? I also personally think the word `string' should be left free, in the long run, for Python programmers to use, on the ground that modules should not be named after common words programmers would like to keep to themselves as variable names. So, I think _nothing_ should be added to the `string' module, with the effect of nailing it deeper in the library, even if there is a need to rush some solution in. -- François Pinard http://www.iro.umontreal.ca/~pinard