[Python-Dev] Re: Deprecation process (random vs whrandom)
Wed, 10 Apr 2002 11:12:12 +0200
Guido van Rossum wrote:
> > I added warnings to statcache & xmllib which are deprecated in the docs.
> > Any others need to be done? Should statcache be removed from test_sundry?
> > Should any modules be moved into lib-old? posixfile?
> A good exercise would be to do a 1-minute review of every module in
> the library and decide for yourself if you'd deprecate it if you were
> BDFL. I'll gladly review the list.
I must say that I'm not very thrilled about the PythonLabs
strategy to go about and deprecate lots of modules which have
been in use for years, documented in many Python books, used
as examples in tutorials, slides, newsgroup postings, etc.
just for the fun of it.
What has happened to the conservative strategy of achieving
backwards compatibility as highest priority ?
Why can't whrandom simply redirect to random ? (without
deprecation warnings which confuse newbies and bother
Why do we have to deprecate code which was replaced
with a compatible API in a differently named module ? (it
can't be the few bytes we save in the distro...)
I don't see the point of carelessly breaking stuff for
cosmetic reasons. I'm not at all objected to replacing
older technology with new one, but I am worried about
the way this is done.
To me, all this generates is FUD, but unfortunately this
time for a very real reason... you can no longer be sure
that your script which you wrote two years ago will still
run with the Python version released within the next year
and that's seriously bad publicity for Python which has
had a long track record of being a very stable, very neat
platform for writing code that you can not only *read*
two years after having written it, but also run without
Hmm, I should add a smiley somehwere here... :-) <-- there
it is ;-)
CEO eGenix.com Software GmbH
Company & Consulting: http://www.egenix.com/
Python Software: http://www.egenix.com/files/python/