[Python-Dev] Rewriting PEP4

[Raymond Hettinger]

> > 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.
> 
> Ok, that might be reasonable.

Please word the PEP accordingly.


> > 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.
> 
> I disagree. The primary purpose (move developers to the alternative
> approach) is achieved as soon as the warning is added, and the
> documentation is deleted. Whether the module is actually deleted is
> of minor importance: it costs nothing to continue including it; disk
> space is cheap.

That is reasonable.  Please make that goal/assumption explicit in the
PEP.



> > 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.
> 
> You could remove it now, but if we release Py2.5 in two months, you
> would have to put it back in. So if you don't have time then, maybe
> somebody else will. If nobody has time to remove the module, the next
> release will ship with it, again - no big issue.

Okay.  Again, please say that in the PEP.


> > 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).
> 
> That is true.

That should also be recommended in the PEP.  



> > If we really don't care whether it gets done, then we shouldn't
bother
> > in the first place.
> 
> What do you mean by "bother"? Not put the deprecation warning in? We
> do want users to move to the new approach of doing something. However,
> two version are just not enough - it may take 10 or 20 years to remove
> a widely used feature (e.g. the string module). That it will take so
> long does not mean we should not start the process *now* - if we start
> the process in five years, it will *still* take 10 or 20 years. Just
> be patient.

I see.  That also may useful to include in the motivation section of the
PEP.

With these adjustments, I think the PEP will be fine.   Also, be sure
get rid of the mid-version undo (see Anthony's note) and to address the
situation with Python books.

I look forward to a revised draft.


Raymond