[Python-Dev] deprecating string module?

[M.-A. Lemburg]

Skip Montanaro wrote:
>     mal> There's a good example of what I was talking about in the
>     mal> "Stability and Change" thread: careless use of deprecations would
>     mal> cause serious grief among developers and certainly also users (who
>     mal> are then confronted with tons of warnings which they don't
>     mal> understand).
> 
> I don't believe I said "let's carelessly deprecate the string module". 

Looking at the subject line, you're almost there ;-)

>     mal> Now for Python modules the situation is a little better, since it
>     mal> is possible to wrap up those deprecated modules in a distutils
>     mal> package for users to install on top of their Python install.
> 
> I don't see why this can't be done for string.py.

Sure it can; don't see what we gain, though.

Note that I was just addressing the more general case discussed
in the other thread "Stability and change".

>     mal> BTW, I don't see the tradeoff in saving 11k worth of diskspace for
>     mal> string.py compared to the good vibes we lose in the Python world
>     mal> for this.
> 
> It has nothing to do with 11k worth of disk space and everything to do with
> "there's one (best) way to do it".

That's a silly phrase. I agree that there should always be a
straight-forward and intuitive way to do things, but I don't go
for such a dogma type argument and I'm sure you don't
either :-)

The intuitive way to do e.g. string.find has changed from

	import string
	string.find(x,y)

	to

	x.find(y)

and that's worth making clear, but forcing the Python people
to change their previously adapted intuition sounds too much
like dictatorship to me.

If I want to write code which works in all Python versions starting
from 1.5.2 onwards, I should be able to do this. Deprecating
important modules like string and types and then removing them
altogether makes this impossible without extra hackery or
providing special bwcompat packages to the users.

Just look at the hoops which the email package has to go through
to maintain such compatibility. That's not the old Python
philosophy I'm used to and that's also why I dislike the
idea to rip out code for no apparently needed reason at all.

-- 
Marc-Andre Lemburg
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/