[Python-Dev] Deprecating whrandom; and deprecating in general

[Guido van Rossum]

> > [MAL]
> > > Some existing scripts still use e.g. regex which is deprecated
> > > and probably will get removed from the core distribution soon.
> > > We can't update that code to use re because the script will have
> > > to expose the exact same semantics as regex provides and I don't
> > > know how to do this reliably with re (pcre or SRE). Note that
> > > these scripts are usually tools which again are used by other
> > > applications, so changing semantics is not an option either.
> > 
> > I'm not sure I understand.  Are these other packages generating
> > regular expressions in the regex syntax that your script then applies
> > somewhere?  This is indeed a problem -- unless you can keep your
> > customers on Python <= 2.2 forever, eventually the regex module will
> > die of old age.
> 
> No, the problem is that the tools get used in e.g. shell scripts
> all over the place, so other software relies on the Python script
> using the regex RE syntax.

Can you be more concrete?  I still don't think I understand it.

> > If you think keeping regex alive is easier, perhaps you can take
> > it up as a 3rd party module?  I really don't want to have to have
> > three different regular expression implementations in the Python
> > distribution forever.  (I do understand that deprecating and
> > removing a very heavily used package like regex needs to be done
> > more carefully than e.g. deprecating dircmp, which nobody uses.)
> 
> I can understand that, but I also think that working software
> need not be removed altogether. Rather than moving it to
> some lib-old directory it would be better to add it to a
> separate distutils package which people who wish to
> continue to use these modules can install along with the
> standard Python installation.

But enabling lib-old is a lot easier than downloading and installing a
separate package!  (All it takes is adding it to $PYTHONPATH or
sys.path.  And this can be done on a per-user basis.)

For Python modules, I have no objection to keeping them around in
lib-old forever.  For C code, I think we should be relieved of the
maintenance burden at some point, and then I agree that your separate
download solution works fine.

> To make people aware of this package, python.org should
> link to it. The same could be done for e.g. the Asian
> codecs.
> 
> I think it's worthwhile shipping Python as a core package
> and a standard set of distutils based add-ons.

I expect that most people would never install the add-ons.

> > Is it acceptable to tell customers not to upgrade to newer Python
> > versions, or to coordinate such upgrades with additional installs from
> > you?
> 
> It's acceptable to tell them that they should install a
> special add-on package along with Python ... they'll
> have to do that anyway with the mx extensions, so
> adding another package to the list wouldn't hurt.

Good.

> Sorry for the confusion. I meant a distutils package, not a
> Python package.
> 
> The idea is to move code from lib-old into that a
> separately downloadable distutils package, e.g. 
> python-libold.
> 
> People would then first install Python and then add
> python-libold and possibly python-asiancodecs as
> needed. distutils makes this easy.

Yeah, but most people wouldn't download and install them, and if at
some later point they run some 3rd party code and get an import error,
they may not realize the solution.

> > PyChecker can't check everything.  E.g. a source code inspection can't
> > possibly detect int divisions reliably.
> 
> No, but it certainly can check for 'import whrandom'.

And then again, most Python users have probably never heard of
PyChecker.

> > > * deprecated modules get moved into a separate distutils
> > >   based package and are made available on python.org together
> > >   with the new Python version; the package should contain
> > >   a copy of PEP 4 for the curious reader
> > 
> > If you want to maintain this, OK.
> 
> I'd need help from other developers.

Maybe you can lobby specific individuals who you think may share your
goals.

--Guido van Rossum (home page: http://www.python.org/~guido/)