[Python-Dev] Rewriting PEP4

[Raymond Hettinger]

> I'm happy to adjust details of the procedures - but it seems we
disagree
> 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
the
> > 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.



Raymond