[EMAIL PROTECTED] 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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
