[Python-Dev] Rewriting PEP4 (original) (raw)

Raymond Hettinger python at rcn.com
Tue Dec 7 01:43:07 CET 2004

I would do what Barry suggests: rephrase the module to document the deprecation/removal procedure. This, of course, needs consensus/pronouncement, too, but I think I would put the following aspects into it:

Requirements ============ Removal of module needs proper advance warning for users; the module should be removed only if - continued usage poses a security threat to the application using it, or - there are no reported usages of the module anymore for quite some time - the module is unmaintained (i.e. there are serious outstanding unfixed bugs for it), and there are alternatives which are maintained. There must be a way for users to stop removal of the module, e.g. by volunteering to maintain an unmaintained module.

The effect of coding this into the PEP is to make deprecation unnecessarily involved. Also, the list of reasons is insufficiently comprehensive. In the past we've gotten along fine with discussing a situation on python-dev and either reaching a consensus or having Guido give an okay.

2. a comment must be added just above the warning, giving a the date and version of deprecation, and a rationale for removal (e.g.: no known users, is security risk)

We should only talk in terms of versions. Dates are irrelevant and confusing. In the last version of the PEP, it was far from clear the significane of deprecating or removing on date xx-xx-xx. All that matters is the version the warning first appears and the version where the module is removed.

Modules that have currently deprecation messages in them often fail to identify the Python version in which removal will occur. For modules that have been deprecated since 2.1, I would suggest to remove them for 2.5, with the option of bringing them back in 2.5.1 if people complain.

I do not think the version number messages are useful. When someone imports a file and gets a warning, they know a deprecation is pending and to stop writing code with that module. Further, I want to avoid the previous PEP 4 situation where one nit or another wasn't followed to the letter so we had to keep the module around for another two versions. It can and should be as simple as having us agree to deprecation, inserting a warning, and then removing it two versions later.

Also, we need to shy away from the idea of having 2.5.1 with different capabilities than 2.5. This sort of thing is a portability disaster. Anthony, please speak up.

General comments:

I had thought the purpose of rewording the PEP was just to take out language naming specific modules and to add language on using the warning module. Instead, it looks like an attempt to make it much more difficult and slow to deprecate a module.

If so, I would like to understand what situation is motivating it. Is there some module that had been deprecated but should not have been? Why the change in procedure?

It doesn't affect me personally (I haven't proposed any modules for deprecation and do not have any in mind); however, I think the discussion should take place in the broader context of what we intend to do with the standard library -- do we want regex still there in 2010.

Also, as proposed, the PEP lists many forces against deprecation and none of the forces for it. If that is the reality, then we could just never deprecate anything because someone, somewhere is bound to be irritated by it. That would certainly simplify the discussion.

Going back to specifics, it may be worthwhile to think through the reason we kept the xmllib code but not whrandom. Both were documented, non-buggy, tested, marked as deprecated for a long time, and it was within the realm of possibility that some code still used them.

Also, the PEP should discuss the use of the lib-old directory and it should include Barry's link to old documentation.

Raymond

More information about the Python-Dev mailing list