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

M.-A. Lemburg mal@lemburg.com
Thu, 11 Apr 2002 18:00:18 +0200

Guido van Rossum wrote:

[Note changed subject]

Thanks for taking time to answer my concerns.

[MAL] > > You won't have much luck in doing s/whrandom/random/g on a > > hard-copy Python text book and this is what Python newbies > > read. I'm not even talking about potential Python users who > > haven't gotten the slightest idea what sed is... :-)

[Aahz] > What Python textbooks use whrandom? > > > Note that the key point is a different one: every single > > deprecation causes work (convincing management, code changes, > > tests, deployment of the new code, training application > > developers, writing/buying new books). Work costs money. > > Money causes all sorts of problems. > > Would it be okay with you for whrandom to emit a deprecation warning, > but not get deleted until Python 3.0? > > From my POV, what you're missing in this debate is the cost of > keeping the code. If code exists, people ask questions about it. > Random issues keep popping up on c.l.py and the simpler the > situation, the easier to explain it.

I am fine with people asking questions about it. In fact, for my customers I will probably create a special package which contains all the deprecated and/or removed code (without the deprecation warnings) -- perhaps we should augment the deprecation process to provide such a package as separate Python download to everybody ?!

As an example for the reasoning here:

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.

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.

[PEP 4 comments]

Now we need a rationale. AFAICT the rationale for deprecating whrandom is that its functionality is a duplicate of the random module, we don't want to have to maintain (and answer questions and bug reports about) both modules, and the name is "wrong" (it refers to a specific random algorithm which is known to be rather weak). That's not a particularly strong rationale: there are only three very old SF bug reports about it, and the revision history has been quiet since January 2001. All changes after July 1998 seem to have been cosmetic, from whitespace normalization to a docstring sweep (this can be used as an argument pro or con deprecation). Groups.google.com shows plenty of recent mention of it in c.l.py (a couple per month), so it doesn't appear that nobody is using it. 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

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

Now on to Marc's argument against deprecation:

> > If not absolutely needed in order to make way for new techniques > > or features, we should leave the old established code in place > > rather than causing endless support sessions with customers > > who fear that the code you've written for them 6 months ago > > starts making not so funny noises or that drag you to update > > the code on a warranty basis. > > > > What's worse, is that management will not be delighted to > > see that this "new technology we use, called Python" causes > > quality assurance and training costs every 8-12 months. I > > wouldn't want Python to go down that road, now that the > > ball is starting to roll. I think there are two different typical use cases for Python code, and they have different preferences for deprecation (and other) warnings. 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.

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.

Use case #2 is Marc-Andre's and Fredrik's situation: a company writes a program in Python which runs at a customer's site. Assume the program is not large and self-contained enough to warrant it coming with its own version of Python. The customer has lots of Python code in production, maybe some that they wrote themselves, some that they bought from different places, and maybe even some open source downloads.

At some point the customer decides to upgrade their Python -- maybe because they like to be on the bleeding edge for their own code base, maybe because they need this for a new open source download, maybe they believe it will fix some Python problem they've experienced intermittently. Now the program they brought from PythonWare or from eGEnix suddenly starts to emit a warning each time it is run. 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.

How do we satisfy both use cases? We could turn off deprecation warnings by default. But I suspect that most programmers in use case #1 would probably never turn on deprecation warnings, thereby defeating the point of them.

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.

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.

So how about this:

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

-- Marc-Andre Lemburg CEO eGenix.com Software GmbH

Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/