[Python-Dev] deprecating string module?

[Steve Holden]

----- Original Message -----
From: "M.-A. Lemburg" <mal@lemburg.com>
To: <skip@pobox.com>
Cc: <python-dev@python.org>
Sent: Wednesday, May 29, 2002 7:54 AM
Subject: Re: [Python-Dev] deprecating string module?


> Skip Montanaro wrote:
[on carelessness]
>
> >     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.
>
Well, one thing we would gain is that new users would be educated by the
depracation warnings. If nslookup is allowed to tell me

"""Note:  nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead.  Run nslookup with
the `-sil[ent]' option to prevent this message from appearing."""

then it seems reasonable for Python to say "If you carry on programming like
this you will (albeit eventually) come a cropper". The problem that (for
instance) the Python Business Thingy might have with this is that it looks
like they don't know their job if their software starts to barf all over the
operating environment when a new version of Python is deployed. Their
customers (or their ISPs) will report that a Python upgrade has "broken
something", and that's not good PR.

> 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 :-)
>
"That's a silly phrase" is a silly phrase <0.36759 wink>.

Dogma, shmogma. None of us buy the "there can be only one way to do it"
philosophy, which clearly isn't Pythonic. Not when I'm the arbiter, anyway.

While there will *always* be "more than one way to do it", I might be
persuaded that a "single most obvious" way is desirable, and the more common
the use cases the more desirable it is. Unless it's *really, waaay* too
slow. The important thing is to cut down the repertoire of "micro design
patterns" commonly used by literate Python programmers. This will tend to
help the readability of actively maintained code.

> The intuitive way to do e.g. string.find has changed from
>
> import string
> string.find(x,y)
>
Clearly not for everybody <wink>.

> 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.
>
Well, I think you're both right (sickening, isn't it). The problem is the
"Python-puke" from production systems. If a script is run frequently (as a
popular CGI, or similar) it's going to puke a lot, and (to the sysadmins)
probably quite visibly.

> 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.
>
I can understand this, but isn't "1.5.2" a little arbitrary. And when does
"1.5.2" become something else, and should it be "2.2.3" or "3.0.7"? There
will, inevitably, come a point when  Python X.Y's new features offer
radically more efficient and/or easily-maintained paradigms for certain
tasks to the extent that maintaining 1.5.2 compatibility will be a real
loss.

> 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.
>
I understand both the words and the feelings behind this statement, and
support them both. The warning system seems fine to me, but...

Suppose that a feature used in existing [Python] code is depracated as a
result of a minor (N.X -> N.Y). This should not affect production systems,
but should definitely instigate warnings in the development environment.

If the depracation warnings were deactivated *for code sourced before the
release date* then

    1. a commercial "product" of the Python Business Thingy would have the
maximum lifetime consistent with feature support in Python,
    2. developers would know for three release cycles how to maintain their
code, and
    3. if an unsuspecting sysadmin makes a minor edit to the code (aha, this
release is being "actively maintained") then that particular module starts
barfing.

Of course this does have the slight downside that when feature support *is*
finally removed, death is immediate and terminal. This might not be an
altogether bad thing, and in a web server might be regarded as indicating
time to seek the Happy Hunting Grounds.

regards
-----------------------------------------------------------------------
Steve Holden                                 http://www.holdenweb.com/
Python Web Programming                http://pydish.holdenweb.com/pwp/
-----------------------------------------------------------------------