[Python-3000] After 2.6 should be 3.0 (original) (raw)

Josiah Carlson jcarlson at uci.edu
Wed Apr 19 09🔞06 CEST 2006

"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?)

More information about the Python-3000 mailing list