[Python-Dev] deprecating string module?

[Alex Martelli]

On Wednesday 29 May 2002 02:35 pm, Fredrik Lundh wrote:
> Steven Lott wrote:
> > The true majority are the "yet to start" users, for whom the
> > String class will be the only thing they ever use; irrespective
> > of the deprecation state of string.
>
> you mean we should burn all existing python books, and
> start over from scratch?

All author of Python books should heartily second this
recommendation -- unless the book is right in the sweet spot
of its lifecycle curve, where it's selling well without needing
any edits and updates, of course (so, please let's do it AT
ONCE, before the Cookbook and Nutshell come out, or
better wait a hopefully long while for their sales to get on a
downward slope).  After all, in terms of editing work, moving
any reference to the string module to an appendix on "old
deprecated stuff that you only need to know when migrating
old code to new Python releases" is pretty modest, and yet
it will let us make "new importantly updated editions" and sell
a bunch more to suck^H^H^H^H discerning book buyers who
_know_ they must always have fully updated tomes.

Then when THAT sales boost has died down, we can make
another killing by introducing, say, a boolean type with two
constants True and False that act just about the same as
1 and 0 but also let us make another crucially updated edition
(with a gain in readability for our prose, too).  Hmmm, maybe
_this_ one is a bit too obvious as a ploy to sell new updated
editions.  But I'm sure we can come up with something.


Seriously for a sec: I'd _love_ not to have to explain why most
but not all string methods are ALSO in a string module without
making it sound as if Python's so encrusted with "needless but
backwards-compatible cruft" to make it a match for C++ -- which
it isn't, by a long shot, but that ain't easy to communicate.  On
the other hand, using False and True in explanations instead of
0 and 1 _does_ enhance prose readability -- interesting side effect
I guess:-).

I'd just love it if old cruft could be removed, but each time that
is mooted, there's an uproar.  So I guess we just have to live
with a slow accumulation of "more than one way to do it" (at
least until the mythical will-never-come backwards-incompatible
Python 3000, of course) despite the obvious costs (each time
two coders get used to different idioms for the same task, they
will have a slightly harder time maintaining each other's code).

The costs always look small (for each single issue -- there are
many small things...), and are spread over time; the benefits
always appear more obvious (don't break MY code, let me
keep some backwards compatibility with 1.5.2, let me keep my
own habits...) and immediate.  So, no matter what the actual
value of the cruft-removing proposal might be, the uproar
against it is inevitably loud, and cruft stays and keeps piling up.

Languages always grow, never shrink.  I love it when Python
manages to do otherwise once in a while (e.g., xrange's cleanup),
but I doubt it can happen often enough to make a difference.
Oh well.


Alex