[Python-Dev] Rewriting PEP4
python at rcn.com
Tue Dec 7 08:50:55 CET 2004
> I'm happy to adjust details of the procedures - but it seems we
> on the principles.
Not really. I have no objection to making module deprecation/removal
rare or even not doing it at all. Personally, I've never asked for a
module deprecation and don't expect to.
I also agree that more public participation is a wise step.
I would just like to see a clean, actionable PEP. To me, the draft text
outlined a timid, faltering process that would be hard to follow, prone
to reversal, and accomplish little.
I especially find burdensome the obligation to undo a deprecation the
moment some random user sends a grumpy email.
Instead, there should be a clear decision to deprecate or not. If that
entails a comp.lang.python.announce notice and comment period, so be it.
Once a decision is made, document it, add a warning, and wait.
Once a couple versions pass, some useful action needs to take place. If
the code is left in-place and the doc index is just re-arranged, then we
would have been better off not doing anything at all.
Ideally, the PEP should also provide some informational value. It
should list Barry's link as a reference for old docs. It should
describe the appropriate use of lib-old (like whrandom) vs. renaming a
module (like stringold) vs. leaving it in-place (like xmllib) vs.
removing the module
The questions of dates was somewhat minor. I was unclear on the
implication of, for example, "remove on 15Jan2005". Since Py2.5 won't
go out for at least a year, does that mean that the work can't be done
now while I have time instead of later when I don't. The only time the
removal becomes visible is when a new version goes out the door.
Further, if a version is going to have something removed, we should do
it at the outset rather than just before a release goes out the door (to
allow for early surfacing of any issues).
> > Further, I want to avoid the
> > previous PEP 4 situation where one nit or another wasn't followed to
> > letter so we had to keep the module around for another two versions.
> Why do you want to avoid that situation? What is the problem with
> waiting for two more versions? No harm is done in doing so.
If we really don't care whether it gets done, then we shouldn't bother
in the first place.
More information about the Python-Dev