[Python-Dev] Update PEP 292

[Raymond Hettinger]

[Barry]
> Now for the controversial bit <wink>.
> 
> 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 safe_template 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.