[Python-Dev] Deprecating whrandom; and deprecating in general (original) (raw)

Guido van Rossum guido@python.org
Thu, 11 Apr 2002 12:43:51 -0400

[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.

Perhaps what's necessary is a translation module that translates the regex syntax into re syntax? Such a module could be provided as part of future releases as regex, without deprecation (at least until you stop using it :-).

Granted, creating such a translation module is a one-time effort, but it seems inevitable that the current regex module will eventually stop working.

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.)

It is acceptable to tell sys-admins of our customers to install the one extra package when they update Python, it is not acceptable to require them to change existing code and it's a maintenance nightmare to provide them with updated software since it is not actively being maintained anymore or was specifically written for the customer.

Is it acceptable to tell customers not to upgrade to newer Python versions, or to coordinate such upgrades with additional installs from you?

[Guido]

> Suppose we decide to deprecate whrandom. The first opportunity to do > so will be in 2.3. (I think we shouldn't deprecate modules in micro > releases; the PEP is silent about that but I think it would be a bad > idea.) Then it will have to continue to exist for at least a year. > Because whrandom is still in active use (see above), I think the one > year deprecation period is too short in this case and we should use > two years. Maybe the warning should only be introduced in the second > year? That probably means (assuming releases every 6 months): > > 2.3 - deprecate in docs > > 2.5 - issue warning > > 2.7 - move to Lib/lib-old

[MAL]

Perhaps we could make Lib/lib-old a separate package ?!

I'm not sure what you're proposing. A separate distribution? Or a Python package, which would have to be renamed to e.g. lib_old and from which you could then import it using "from lib_old import whrandom" ?

> Use case #1 is what we usually think of. Some programmer is > maintaining some Python code. When he upgrades the Python version > he is using, being the programmer he probably wants to find out > about deprecated features in the new Python version, so that he > can fix his code so that it won't break outright in the future. > IOW, this programmer is glad that there are deprecation warnings > (compared to the alternative, where he had no idea that he was > using a deprecated feature until it was removed and his program > broke outright).

True; however, deprecation warnings are run-time messages and not every module in a package is always used by the programmer, so the warnings may appear after a few months down the road.

Well, that's life.

I would much rather like a tool like PyChecker scan all the code for deprecated modules and maybe a similar tool for the C API.

PyChecker can't check everything. E.g. a source code inspection can't possibly detect int divisions reliably.

> This is annoying: maybe the warning goes to a log file where > unexpected things cause alarms to go off, maybe it shows up in an > end user's shell window where it causes confusion, maybe there are > a lot of warnings and the extra output is simply annoying. These > users probably aren't Python savvy, so they may panic and call > customer service. Understandably, nobody is happy. Marc-Andre > and Fredrik already know their program issues a warning, and > they've fixed it in their own version, and they don't want to > waste time telling every user how to disable or ignore the > warning, or shipping upgrades.

It not so much about wasting time, it's about bad PR: to the customer it appears that you've written malfunctioning code.

Somewhat granted, though it suggests that the customer doesn't understand what they're talking about. Customers always blame the wrong party (e.g. whenever some Windows game breaks the Python installer, Python gets the blame).

> I would like to suggest that instead, professional software > distributors like eGenix and PythonWare tweak their distributions to > turn of warnings by default. This is easy enough: in the main > program, insert > > import warnings > warnings.filterwarnings("ignore") > > at the top (before other imports). If the code needs to run on Python > 2.0 or before, insert the whole thing inside a try: / except > ImportError: pass. If you want an easy way to enable warnings, you > can invent something else (e.g. check an environment variable). > > Would this be acceptable?

Yes.

Great!

I would still like the option to continue using code which was deprecated by PythonLabs. Just because code is unmaintained doesn't mean that it cannot be used anymore.

Granted.

So how about this:

* 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.

* deprecated C APIs are grouped in a file pyold.h which only gets included by Python.h if PyDEPRECATED is defined; that header files should contain a list similar to PEP 4 for the deprecated C APIs and if possible include a description of how to update existing code

I think this is fine too (though I admit I haven't been following the Py_DEPRECATED discussion in detail).

Both techniques aim for stability: they make the deprecation process more visible and they provide downgrade paths for existing installed code.

As long as you and others who will benefit from this help out, I think we can do this.

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