On Sat, May 28, 2011 at 6:40 AM, harrismh777 <harrismh...@charter.net> wrote: > Most 2.x code *will not* run correctly in 3.x/ Most of the best > improvements and enhancements of 3.x will not back-port to below 2.7, and > almost none of them will back-port before 2.6 (class decorations, for > instance).
What's with the "below 2.7"? If you're comparing 3.x and 2.x, wouldn't it be most plausible to compare 3.2 and 2.7? And, the biggest reason for 2.x code not running on 3.x is probably the print function. (Guess made without any data beyond my own personal corpus of Python 2 code.) That's something that can be corrected by, oh, I dunno, the 2to3 translator maybe? And the __future__ import makes 2.6+ work the same way as 3.x. > All of these things are for the better, I must add. But, the point is that > 3.x is completely incompatible with 2.x in real ways. Arguing that this is > *not true* because you are able to create a code block that just happens 'to > work' in all versions (and that hasn't been verified yet) does not in *any* > way 'prove' that 3.x is a compatible dialect--- far from it... its a > straw-man argument. You're correct that one code block does not prove the point. But your argument is just as flimsy. To say that "most" 2.x code is incompatible with 3.x is to deny the 2to3 utility, and you're ignoring the people who deliberately write code that can cross-execute on either version - which is really not that difficult, if you take some care and use __future__ directives. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
