[Python-Dev] Death to string functions!

[Mark Lutz]

As a longstanding Python advocate and user, I find this
thread disturbing, and feel compelled to add a few words:

> > [Tim wrote:]
> > "string" is right up there with "os" and "sys" as a FIM (Frequently
> > Imported Module), so the required code changes will be massive.  As
> > a user, I don't see what's in it for me to endure that pain: the
> > string module functions work fine!  Neither are they warts in the
> > language, any more than that we say sin(pi) instead of pi.sin().
> > Keeping the functions around doesn't hurt anybody that I can see.
> 
> [Guido wrote:]
> Hm.  I'm not saying that this one will be easy.  But I don't like
> having "two ways to do it".  It means more learning, etc. (you know
> the drill).

But with all due respect, there are already _lots_ of places 
in Python that provide at least two ways to do something
already.  Why be so strict on this one alone?

Consider lambda and def; tuples and lists; map and for 
loops; the loop else and boolean exit flags; and so on.  
The notion of Python forcing a single solution is largely a 
myth. And as someone who makes a living teaching this 
stuff, I can tell you that none of the existing redundancies 
prevent anyone from learning Python.

More to the point, many of those shiny new features added 
to 2.0 fall squarely into this category too, and are completely 
redundant with other tools.  Consider list comprehensions
and simple loops; extended print statements and sys.std* 
assignments; augmented assignment statements and simpler
ones.  Eliminating redundancy at a time when we're also busy
introducing it seems a tough goal to sell.

I understand the virtues of aesthetics too, but removing the
string module seems an incredibly arbitrary application of it.  


> If you're saying that you think the string module is too prominent to
> ever start deprecating its use, I'm afraid we have a problem.
>
> [...]
> Ideally, I'd like to deprecate the entire string module, so that I
> can place a single warning at its top.  This will cause a single
> warning to be issued for programs that still use it (no matter how
> many times it is imported).

And to me, this seems the real crux of the matter. For a 
decade now, the string module _has_ been the right way to
do it.  And today, half a million Python developers absolutely
rely on it as an essential staple in their toolbox.  What could 
possibly be wrong with keeping it around for backward 
compatibility, albeit as a less recommended option?

If almost every Python program ever written suddenly starts 
issuing warning messages, then I think we do have a problem
indeed.  Frankly, a Python that changes without regard to its
user base seems an ominous thing to me.  And keep in mind 
that I like Python; others will look much less generously upon
a tool that seems inclined to rip the rug out from under its users.
Trust me on this; I've already heard the rumblings out there.

So please: can we keep string around?  Like it or not, we're 
way past the point of removing such core modules at this point.
Such a radical change might pass in a future non-backward-
compatible Python mutation; I'm not sure such a different
system will still be "Python", but that's a topic for another day.

All IMHO, of course,
--Mark Lutz  (http://www.rmi.net~lutz)