Re: [Python-Dev] Common subset of python 2 and python 3
On Wed, Jan 15, 2014 at 01:22:44PM +0100, Martin v. Löwis 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? IMO Python 2 and 3 do have this part in common when you talk about valid syntax and available methods and functions, but not in terms of behavior. I think a new proposed Python version should simply crash on your example. I'm kind-of playing devil's advocate here because i agree with previous posters that such a Python version is unneccessary with tox and python2 -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? Warnings about using certain string methods on repr() might be a neat thing to add to python -3 or static analysis tools. Regards, Martin ___ 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/markus%40unterwaditzer.net ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Common subset of python 2 and python 3
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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Common subset of python 2 and python 3
On Wed, 15 Jan 2014 13:22:44 +0100 Martin v. Löwis mar...@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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Common subset of python 2 and python 3
On Wed, Jan 15, 2014 at 11:22 PM, Martin v. Löwis mar...@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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Common subset of python 2 and python 3
On 1/15/2014 8:21 AM, Chris Angelico wrote: On Wed, Jan 15, 2014 at 11:22 PM, Martin v. Löwis mar...@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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Common subset of python 2 and python 3
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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Common subset of python 2 and python 3
On Wed, 15 Jan 2014 16:31:17 +0200 Serhiy Storchaka storch...@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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Common subset of python 2 and python 3
On Thu, Jan 16, 2014 at 1:25 AM, Eric V. Smith e...@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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Common subset of python 2 and python 3
15.01.14 16:34, Antoine Pitrou написав(ла): If you explicitly create a long the L will always be printed: long(0) 0L Hey! long is not in common subset of Python 2 and Python 3. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Common subset of python 2 and python 3
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 mar...@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 ___ 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/archive%40mail-archive.com
[Python-Dev] 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? ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Common subset of python 2 and python 3
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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Common subset of python 2 and python 3
On 12 Jan 2014 23:39, Nachshon David Armon nachshon.ar...@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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Common subset of python 2 and python 3
On Sun, Jan 12, 2014 at 3:58 PM, Nick Coghlan ncogh...@gmail.com wrote: On 12 Jan 2014 23:39, Nachshon David Armon nachshon.ar...@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. ___ 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/archive%40mail-archive.com
