On Sun, Jan 12, 2014 at 3:58 PM, Nick Coghlan wrote:

On 12 Jan 2014 23:39, "Nachshon David Armon" 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.

On Wed, 15 Jan 2014 13:22:44 +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?

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 1/15/2014 8:21 AM, Chris Angelico wrote:

On Wed, Jan 15, 2014 at 11:22 PM, "Martin v. Löwis" 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 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" 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

On Wed, 15 Jan 2014 16:31:17 +0200 Serhiy Storchaka 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.