[Python-Dev] Update PEP 292 (original) (raw)

Raymond Hettinger python at rcn.com
Thu Aug 12 23:12:10 CEST 2004

[Barry]

Now for the controversial bit .

I still think it's worthwhile to turn the string module into a package. The sandbox has an implementation of this that is completely backward compatible. I like it because it segregates the deprecated functions into a separate sub-module and makes the whole shebang easier to maintain. It also provides an existing namespace for future expansion, as has been discussed before. Please note: PEP 292 is not dependent on the string module -> package reorganization, so it isn't documented in that PEP. I don't think it's worth writing a PEP just for this library reorganization. Take a look at the sandbox if you're interested. http://cvs.sourceforge.net/viewcvs.py/python/python/nondist/sandbox/stri ng / As far as this aspect of the changes go, I would like BDFL pronouncement on it. I'll abide by Guido's decision here. If he nixes the re-org, then I propose to put the template and safetemplate classes in Lib/string.py. The libstring.tex changes will still be relevant.

After more thought, I would like to voice a strong -1 on the packaging of string.

At the outset, I felt that it introduced unnecessary complexity. Adding a new directory, an init.py, and two modules just to add a few lines of code is overkill. Package logic should be reserved for organizing voluminous code like the email package. Arguably, the logging package should have been just a single module -- putting it in a package just made it more difficult to read and maintain.

To test the existing sandbox code, I moved it into the library and found a circular import issue: importing the string package, causes template.py to be imported, which in turn imports re which uses sre_parse.py, needs to import string. So, the whole thing fails. It is fixable, but it sucks to have to start doing work-arounds from the outset just to compensate for something that adds no value to begin with.

The package has already complicated review and updates. I'm having to re-write it in non-package form just to add doctest (which fails by the way) and other small fix-ups.

My recommendation: Create a stringtools module with the new template stuff in it and with room for growth. Leave string.py alone and let it die in peace.

The business end of the template code is only a few lines long. Wrapping it in a package is like using cannon to kill a mosquito. Let's not make something hard out of something trivially simple.

Raymond

P.S. Side rant: Also, in the last few months, the #ifdefs have multiplied. While I understand that some things like time stamping are worthwhile, the code is getting harder to read and maintain because of all this b.s.

At some point, someone changed a definition and I had to add an #ifdef to import addrinfo.h for VC++ 6.0. I noticed the same had to be done for Cygwin and there was a similar GCC entry. Each checkin was done by a separate person fixing a crash in their own part of the universe. The right answer would have likely been to refactor the original change that mucked up everyone else's compile. Instead we ended up with a pile of conditionals that will be hard to maintain going forward because the surrounding code has become so stiff.

More information about the Python-Dev mailing list