[Python-3000] pre-PEP: Procedure for PEPs with Backwards-Incompatible Changes

[Ian Bicking]

skip at pobox.com wrote:
>     >> Suggestion: Make this PEP 3001 and start any Py3k PEPs from 3100....
> 
>     Guido> I already proposed that numbering scheme. More formally, Py3k
>     Guido> meta PEPs go between 3001 and 3099, and feature PEPs start at
>     Guido> 3100 (and hopefully we won't have to overflow into 4000 :-).
> 
> Should there be some distinction between Py3k PEPs which fall under the
> purview of Steven's PEP and those which contain completely new stuff and
> aren't going to impact Python 2.x code?

I notice also that some of these suggestions are applicable to 2.x, like 
the "Parallel iteration syntax" (which introduces no backward 
incompatibilities).  If something can be applied to 2.x, should that be 
brought up in py-dev instead (or c.l.p.)?

There seems to be a danger that Py3K is seen as a more friendly place to 
suggest changes than Python 2.x (or maybe that the python-3000 list is 
more friendly to these suggestions than py-dev), and so changes are 
brought up here even though they could be applied earlier.  This would 
be problematic in part because if a change *can* go in 2.x, it would be 
really good if it did, so that the move to 3.0 involves as few changes 
as possible.

Formalizing the target implementation through the PEP numbering might 
also cause premature expectations about when the feature might be 
introduced.  Though if it's okay to just renumber the PEP then that 
wouldn't be a problem.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org