Common subset of python 2 and python 3
Hi, I am Nachshon and this is my first post to the python mailing list. I have been porting some libraries from python 2 to python 3 recently with the goal of a common codebase that will run on both versions. I was thinking it would make my life, and a lot of other developers as well, a lot easier if there were a version of python that supported ONLY the features found both in python 2 and python 3. It should be a developer only version of python. It should use unicode strings and require that people use the from __future__ syntax so that anything written in it will work in python 2.7 and in python 3.3+. Regarding name changes of standard library modules it should support the new stuff and have helper functions and guides that make the old modules likethe new ones. it should encourage using backports of the new standard library modules like enum so that developers are not stuck for features. I propose that this new version of python use the python 3 unicode model. As the version of python will be fully compatible with both python 2 and with python 3 but NOT necsesarily with all existing code in either. It is designed as a porting tool only. I suggest that this new python version should be called python 2 and 9 tenths. Is it worth it for me to write a pep that suggests this?
Hi Nachson, Python 2.7 with the -3 warning flag covers most of this, while using tox to run automated tests under both 2.x and 3.x should cover the rest (tox is also useful for checking code runs under Python 2.6, even if you normally use a newer version). Is there anything in particular you feel isn't covered by the combination of those two approaches? Regards, Nick.
On 12 Jan 2014 23:39, "Nachshon David Armon" <nachshon.armon@gmail.com> wrote:
Hi, I am Nachshon and this is my first post to the python mailing list.
I have been porting some libraries from python 2 to python 3 recently
with the goal of a common codebase that will run on both versions. I was thinking it would make my life, and a lot of other developers as well, a lot easier if there were a version of python that supported ONLY the features found both in python 2 and python 3. It should be a developer only version of python.
It should use unicode strings and require that people use the from
__future__ syntax so that anything written in it will work in python 2.7 and in python 3.3+.
Regarding name changes of standard library modules it should support the
new stuff and have helper functions and guides that make the old modules likethe new ones. it should encourage using backports of the new standard library modules like enum so that developers are not stuck for features.
I propose that this new version of python use the python 3 unicode model.
As the version of python will be fully compatible with both python 2 and with python 3 but NOT necsesarily with all existing code in either. It is designed as a porting tool only. Ah, I missed this on the first read through - that combination of requirements doesn't quite make sense (the text models are fundamentally incompatible in a way that forces developers to resolve ambiguities that Python 2 would silently tolerate until it hit a bad combination of input data). You may want to take a look at the "python-future" project - that comes as close as anything else I am aware of to allowing you to write Python 2 code that reads like idiomatic Python 3 code. Cheers, Nick.
I suggest that this new python version should be called python 2 and 9 tenths. Is it worth it for me to write a pep that suggests this?
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
On Sun, Jan 12, 2014 at 3:58 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 12 Jan 2014 23:39, "Nachshon David Armon" <nachshon.armon@gmail.com> wrote:
I propose that this new version of python use the python 3 unicode model. As the version of python will be fully compatible with both python 2 and with python 3 but NOT necsesarily with all existing code in either. It is designed as a porting tool only.
Ah, I missed this on the first read through - that combination of requirements doesn't quite make sense (the text models are fundamentally incompatible in a way that forces developers to resolve ambiguities that Python 2 would silently tolerate until it hit a bad combination of input data).
while that is true, it is possible to program unicode correctly in python 2 while remaining compatible with python 3. (a combination of "from future import unicode_literal" and properly using the encode and decode functions.). I would prefer a stripped version of python 3 that does not support anything that will really conflict with python 2. for porting purposes only of course. my employer still uses python 2 so the idea is to force other developers to use something that will force working on both during the transition without every single one having to be extra careful to support both versions.
Am 12.01.14 18:39, schrieb Nachshon David Armon:
I propose that this new version of python use the python 3 unicode model. As the version of python will be fully compatible with both python 2 and with python 3 but NOT necsesarily with all existing code in either. It is designed as a porting tool only.
I don't think that it is possible to write an interpreter that is fully compatible for all it accepts. Would you think that the program print(repr(2**80).endswith("L")) is in the subset that should be supported by both Python 2 and Python 3? Notice that it prints "True" in Python 2 and "False" in Python 3. So if this common-version interpreter *rejects* the above program, which operation (**, repr, endswith) would you want to ban from subset? Regards, Martin
On Wed, 15 Jan 2014 13:22:44 +0100 "Martin v. Löwis" <martin@v.loewis.de> wrote:
Am 12.01.14 18:39, schrieb Nachshon David Armon:
I propose that this new version of python use the python 3 unicode model. As the version of python will be fully compatible with both python 2 and with python 3 but NOT necsesarily with all existing code in either. It is designed as a porting tool only.
I don't think that it is possible to write an interpreter that is fully compatible for all it accepts. Would you think that the program
print(repr(2**80).endswith("L"))
is in the subset that should be supported by both Python 2 and Python 3?
Notice that it prints "True" in Python 2 and "False" in Python 3.
We probably need an "asciibool" that is both true and false. (for some value of "we" ;-)) Regards Antoine.
On Wed, Jan 15, 2014 at 11:22 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I don't think that it is possible to write an interpreter that is fully compatible for all it accepts. Would you think that the program
print(repr(2**80).endswith("L"))
is in the subset that should be supported by both Python 2 and Python 3?
Easiest fix for that would be to have long.__repr__ omit the L tag. Then it'll do the same as it would in Py3. ChrisA
On 1/15/2014 8:21 AM, Chris Angelico wrote:
On Wed, Jan 15, 2014 at 11:22 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I don't think that it is possible to write an interpreter that is fully compatible for all it accepts. Would you think that the program
print(repr(2**80).endswith("L"))
is in the subset that should be supported by both Python 2 and Python 3?
Easiest fix for that would be to have long.__repr__ omit the L tag. Then it'll do the same as it would in Py3.
I think Martin's point is not this specific thing, but that such a subset would be useless. Would you drop dict.items() because it returns different things in both languages? Drop range() because it's different? There are many, many such differences. The common subset is not useful. Eric.
On Thu, Jan 16, 2014 at 1:25 AM, Eric V. Smith <eric@trueblade.com> wrote:
Easiest fix for that would be to have long.__repr__ omit the L tag. Then it'll do the same as it would in Py3.
I think Martin's point is not this specific thing, but that such a subset would be useless. Would you drop dict.items() because it returns different things in both languages? Drop range() because it's different? There are many, many such differences. The common subset is not useful.
Fair enough. ChrisA
On Wed, Jan 15, 2014 at 09:25:04AM -0500, Eric V. Smith wrote:
On 1/15/2014 8:21 AM, Chris Angelico wrote:
On Wed, Jan 15, 2014 at 11:22 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I don't think that it is possible to write an interpreter that is fully compatible for all it accepts. Would you think that the program
print(repr(2**80).endswith("L"))
is in the subset that should be supported by both Python 2 and Python 3?
Easiest fix for that would be to have long.__repr__ omit the L tag. Then it'll do the same as it would in Py3.
I think Martin's point is not this specific thing, but that such a subset would be useless. Would you drop dict.items() because it returns different things in both languages? Drop range() because it's different? There are many, many such differences. The common subset is not useful.
To expand on this, the common subset is not useful, not well-defined, and it is not needed. Not well-defined because neither "Python 2" nor "Python 3" are well-defined. Most of the code I write supports Python 2.4 onwards, and there are a lot of features (including syntax!) that exist in 2.7 but not 2.4. Likewise there are features in 3.3 that aren't in 3.2. But most importantly, limiting yourself to just the common subset isn't needed to write polyglot code that works over 2.x and 3.x. For the most part, a few conditional tests will let you write code that works across multiple versions. I prefer to check for features than test the version number: try: next except NameError: # Python 2.4 or 2.5 def next(obj): return type(obj).__next__() sort of thing. Syntax changes are more difficult to deal with. I deal with the lack of ternary if operator in 2.4 by just avoiding it. The other day I really, really wanted to use a with statement, but still be compatible with 2.4. I started off messing about with exec, but eventually rejected that in favour of a conditional import: I lifted that one function using a with statement into a module of its own, then tried importing it. If it failed, I fell back to a second module which implemented the same thing using nested try...except blocks. There's a tiny bit of duplicated code, but less than a dozens lines including a docstring. Given how easy it usually is to write 2/3 compatible code, I don't think that limiting myself to a subset that works unchanged in both would be useful to me. That would be a step backward, like going back to Python 1.5 or 2.0, where the language is still recognisably the same, but it's missing so many features we take for granted that it's painful to work with. -- Steven
15.01.14 14:22, "Martin v. Löwis" написав(ла):
I don't think that it is possible to write an interpreter that is fully compatible for all it accepts. Would you think that the program
print(repr(2**80).endswith("L"))
is in the subset that should be supported by both Python 2 and Python 3?
Notice that it prints "True" in Python 2 and "False" in Python 3.
This is implementation details. On 128-bit platform special build of Python 2 can print False. Of course there are many other differences between Python 2 and Python 3 besides unicode model and unified integers.
On Wed, 15 Jan 2014 16:31:17 +0200 Serhiy Storchaka <storchaka@gmail.com> wrote:
15.01.14 14:22, "Martin v. Löwis" написав(ла):
I don't think that it is possible to write an interpreter that is fully compatible for all it accepts. Would you think that the program
print(repr(2**80).endswith("L"))
is in the subset that should be supported by both Python 2 and Python 3?
Notice that it prints "True" in Python 2 and "False" in Python 3.
This is implementation details. On 128-bit platform special build of Python 2 can print False.
If you explicitly create a long the L will always be printed:
long(0) 0L
Regards Antoine.
participants (8)
-
"Martin v. Löwis" -
Antoine Pitrou -
Chris Angelico -
Eric V. Smith -
Nachshon David Armon -
Nick Coghlan -
Serhiy Storchaka -
Steven D'Aprano