[Python-Dev] deprecating string module?

[Skip Montanaro]

    >> How about deprecating the string module?  

    Martin> I think one needs to offer the alternatives first, and deprecate
    Martin> the module then. So have alternatives for *everything* in string
    Martin> available in 2.3, deprecate it in 2.4, add a DeprecationWarning
    Martin> in 2.5.

I don't see that as being a major problem.  As I mentioned in my reply to
Peter Funk, I believe you can probably let the deprecation schedule slip
according to how important continued 1.5.2 compliance is determined to be
down the road.  That is, deprecate it no earlier than 2.4 and add a
DeprecationWarning no sooner than one or two releases after that.

The following string module functions don't seem to have equivalent string
methods:

    zfill - only because string.zfill accepts non-string arguments,
    otherwise it is already available

    capwords - I believe it was explicitly decided to not implement this as
    a string method

    maketrans - shouldn't be too hard to rewrite in C as a method of str.

Also, the data objects obviously have to be put somewhere.  Before doing any
of this, we need to decide where this stuff belongs.  I doubt the technical
effort involved will be too challenging.

Skip