[Python-Dev] deprecating string module?
Wed, 29 May 2002 09:44:52 +0200
Peter Funk wrote:
> Skip Montanaro wrote:
>>I know this has been discussed before. In light of the recent PEP8 update:
>> Avoid the use of the string module; instead use string methods.
>> These are always much faster and share the same API with unicode
>>I thought I'd raise it again.
>>How about deprecating the string module?
> I'm absolutely against depreceating the string module!
> Instead I suggest to change the cited wording from PEP8 into
> Avoid the use of the string module unless you want to keep
> compatibility with Python 1.5.2; instead use the string methods
> introduced in later releases of Python. These are always much
> faster and share the same API with unicode strings.
> Python 1.5.2 is still very important and even the latest Red Hat
> distributions still use it. Since the bytecode (.pyc) has changed
> inbetween, we decided to ship all our Python Software with 1.5.2
> and backport useful new library modules from 2.x to 1.5.2 if we want
> to use them.
> Of course the edits needed to turn string method calls back into
> string module function calls for 1.5.2 are trivial but they are
> nevertheless tedious. Very often the overall performance win of
> using string methods will be so negligible, that I tend to believe
> that the CPU cycles saved due to this change don't sum up to the
> amount of programmer time wasted by editing Python software from
> string function calls into string method calls or vice versa.
There's a good example of what I was talking about in the
"Stability and Change" thread: careless use of deprecations
would cause serious grief among developers and certainly also
users (who are then confronted with tons of warnings which they
Now for Python modules the situation is a little better,
since it is possible to wrap up those deprecated modules
in a distutils package for users to install on top of
their Python install.
However, when touching core features
of the language things become completely unmanageable. The
reason is that various extensions out there start to rely
on features which are only available in later releases
while others are not migrated yet to these versions and
would result in endless streams of deprecation warnings
or even failures. As a result you'd lose the ability to
fish in the sea of Python extensions...
BTW, I don't see the tradeoff in saving 11k worth of diskspace
for string.py compared to the good vibes we lose in the
Python world for this.
CEO eGenix.com Software GmbH
Company & Consulting: http://www.egenix.com/
Python Software: http://www.egenix.com/files/python/
Meet us at EuroPython 2002: http://www.europython.org/