- backwards compatible with the latest release of Python 2
- contain all features of Python 3 in some form
I think this will result in a very speedy adoption.
In the future I propose the following numbering scheme: for any N > M, Python N contains all features of Python M and is backwards compatible with Python M if and only if M divides N.
> - backwards compatible with the latest release of Python 2
> - contain all features of Python 3 in some form
I'm lost for words.
Feature: print function.
Implementation: from __future__ import print_function
Yes, that magical, backwards-incompatible, print function has been in Python 2 all along!
Feature: unicode strings
Implementation: from __future__ import unicode_literals
Amazing! The magical, backwards-incompatible unicode strings backported to Python 2 with one single line.
I could go on and on.
Except it's not even slightly close to that is it. unicode_literals is something completely different.
How about removing old style classes? Is `class x:` old style or new style in Python 2, in this imaginary interpreter of yours? How about the default object comparison being sane in Python 3. How about the changes to builtins returning iterables over lists? How about the import system being more sane? How about removing backticks? How about actually handling the unicode differences?
I could go on and on, and I hope your answer is not 'well we just need more __future__ imports don't we'.
The question is whether programming in one version vs the other is more enjoyable.
It is possible to work in a subset of python2 and python3 that is syntactically valid under both interpreters but this is not what you are suggesting.
The syntax between 2 and 3 is essentially the same. A few minor tweaks here and there, but nothing major. Your point is a bit pointless because changes to the language that are not on the syntactical level (i.e unicode/bytes) cause the meaning of the code to change, despite the syntax being the same.