>> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4