PEP 292 - simpler string substitutions
PEP 292 describes simpler string substitutions, i.e. $-strings. PEP 320 says that this is going into Python 2.4. I've had some code laying around that implemented $-strings as a subclass of unicode instead of what PEP 292 describes as a new string method. The advantage to this approach is that the feature is provided with no language changes, or changes to the existing string classes.
I've cleaned up my code and posted a patch to SF. I've also checked in an updated PEP 292 that fits my implementation more closely. Please review the PEP and the patch:
http://www.python.org/peps/pep-0292.html
The reference implementation in the patch adds a couple of extra things that aren't part of the PEP, but were discussed at Monday's sprint. Specifically:
- a top level package called 'stringlib' is added to the standard library.
- the dstring class implemented PEP 292 is available through stringlib.dstring
- some handy dict subclasses that work with the dstring class are also provided.
The idea was that some of the constants and functions we want to keep from the string module would go in the stringlib package. That's not essential to the PEP of course.
If this stuff is approved for Python 2.4, I'll add test cases and documentation.
-Barry
Barry> If this stuff is approved for Python 2.4, I'll add test cases and Barry> documentation.
Holding dstrings for ransom, are we? ;-)
nobody-move-or-the-drummer-gets-it-ly, y'rs,
Skip
[Barry Warsaw]
The reference implementation in the patch adds a couple of extra things that aren't part of the PEP, but were discussed at Monday's sprint. Specifically:
- a top level package called 'stringlib' is added to the standard
library.
- the dstring class implemented PEP 292 is available through
stringlib.dstring
- some handy dict subclasses that work with the dstring class are also
provided.
If this stuff is approved for Python 2.4, I'll add test cases and documentation.
This is more generic remarks about the whole PEP process than anything specific about the above work.
Would such stuff be "approved" without going through the PEP first? Should not PEPs represent the full idea, the summary of discussions, and adequately represent the extent of what is being approved, or not?
I sometimes have the feeling that PEPs are used, or avoided, depending on the barometric pressure. :-) Maybe they are used to punch holes in the decision process. Once a hole exists, trucks may go through. Should not PEPs be updated and completed, in particular, when what they describe gets implemented differently, at least saving for the posterity the reasons of the differences? Should not this be mandatorily done _before_ inclusion of a feature into a release? If not that way, many PEPs are going to stay forever incomplete.
participants (3)
-
Barry Warsaw -
François Pinard -
Skip Montanaro