[Python-3000] After 2.6 should be 3.0

[Josiah Carlson]

"Terry Reedy" <tjreedy at udel.edu> wrote:
> "Josiah Carlson" <jcarlson at uci.edu> wrote in message 
> news:20060418200406.A81D.JCARLSON at uci.edu...
> > Personally, I see Py3k as a vetting mechanism for all those hair-brained
> > ideas that really shouldn't make it into any Python version (3k or
> > otherwise), with the possible inclusion of things that *should* make
> > life better for Python users.  With that said, aside from the stdlib
> > reorganization (which should happen in the 2.x series anyways), so far I
> > haven't seen anything that necessitates backwards incompatible changes
> > to Python 3k, and I predict that many of the changes to py3k will be
> > included into mainline 2.x during 3k's development.
> 
> The somewhat backwards-incompatible integer division change discussed and 
> approved some years ago has been suspended pending 3.0, so since I would 
> like to not have to (indefinitely) import 'division' from __future__ to get 
> the change, I too, on that score, would like to see 3.0 sooner than later.


Again, in my opinion, features should necessitate the Python 3.x release. 
Is the integer division change sufficient to necessitate 3.0 after 2.6? 
Goodness, I hope not.

I understand the dislike of repeated __future__ imports (I was using
'from __future__ import generators' for longer than I would have liked
to), but this particular feature doesn't seem to imply to me that 3.0
should come out sooner, rather it says that people should be made aware
of the integer division operation change, and it should make it into the
2.x series (how long have we been talking about integer division changes?)


 - Josiah