[Python-Dev] Rewriting PEP4
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:
> 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
> 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.
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.
More information about the Python-Dev