[Python-Dev] PEP 292 for Python 2.4

Barry Warsaw barry at python.org
Tue Jun 15 23:05:08 EDT 2004

PEP 292 is slated for inclusion in Python 2.4, according to PEP 320.  At
Pycon I checked in my code for this into the sandbox, which I've since
updated, adding unit tests.  I believe it's ready for inclusion in dist
CVS, but I want to get some feedback first.

My new stuff provides two classes, dstring() as described in PEP 292 and
astring() as hinted at in the PEP.  It also provides two dictionary
subclasses called safedict() and nsdict() which are not required, but
work nicely with dstring() and astring() -- safedict re-expands keys
instead of throwing exceptions, and nsdict does namespace lookup and
attribute path expansion.

Brett and I (I forget who else was there for this) talked about where to
situate the PEP 292 support.  The interesting idea came up to turn the
string module into a package, providing backward support for the
existing string module API, then exporting my PEP 292 modules into this
namespace.  This would make the 'import string' useful again since it
would be a place to collect future string related functionality without
having to claim some dumb name like 'stringlib'.  I believe we can still
someday deprecate the old string module functions, retaining the useful
constants, as well as new string-y features.

This is actually not hard to do, and I have this working (and passing
the existing unit tests) in a local checkout.  You simply create the
Lib/string directory, copy or move Lib/string.py to Lib/string/string.py
and do a bit of import-* in Lib/string/__init__.py.  The unit tests all
passed with no changes necessary.  I'd drop my pep292.py file and
safedict.py file into Lib/string and import the useful names out of
there, exposing them in the string namespace.

Is this a good idea?  I dunno, but it seems better to me than adding two
more top-level modules with largely contrived names; nothing better
jumps out to me.  I also really want to include safedict.py if we're
including pep292.py because they're quite useful and complimentary, IMO,
and I can't think of a better place to put those classes either.

I'm open to suggestions.  I have not yet written docs for these new
classes, but will do so once we agree on where they're getting added. 
The code and test cases are in python/nondist/sandbox/string.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040615/76d3fb41/attachment.bin

More information about the Python-Dev mailing list