[Python-Dev] deprecating string module?
Wed, 29 May 2002 06:24:22 -0500
>> 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
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.