[Python-Dev] Re: PEP 292 - Simpler String Substitutions
François Pinard
pinard at iro.umontreal.ca
Mon Aug 23 15:20:43 CEST 2004
[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
More information about the Python-Dev
mailing list