[Python-Dev] Proposed 3.0 compatiblity module

Phillip J. Eby pje at telecommunity.com
Wed Jan 17 00:50:07 CET 2007


At 10:23 PM 1/16/2007 +0000, Steve Holden wrote:
>Phillip J. Eby wrote:
>>At 08:52 PM 1/16/2007 +0000, Steve Holden wrote:
>>>I foresee that many people would be happy restricting their 2.X source
>>>slightly to ensure perfect translation into (working, no necessarily
>>>optimal) 3.0. Under those circumstances the 2to3 tool wouldn't
>>>necessarily have to translate all valid 2.X to 3.0.
>>Actually, it would be several times more preferable to either have that 
>>restricted subset of code run on 3.0 without translation, or for 
>>translated code to still be usable in 2.X.
>>I have often been in the habit of running test suites back-to-back on 
>>multiple versions of Python while doing test-driven development, so 
>>having a repeated translation step would interfere with that.  Ideally, a 
>>translation should be necessary one time only -- in which case requiring 
>>manual cleanup steps isn't as big of a problem.
>>The idea here being that, once 2.6 is widely-enough deployed that it can 
>>be assumed as a base for one's users, you can simply run the translator 
>>once, do any cleanup, and then have 3.0-clean code that also still runs 
>>for your installed base.
>>That way, there's no chasm to leap; just a code cleanup.
>That assumes that once you convert to 3.0 you are no longer interested in 
>back-porting further functionality changes to your 2.X code, surely, or am 
>I missing something?

I'm saying that the 3.0 code would have to be usable in 2.x.  That is, any 
new features added to 3.0 need to be backported to a 2.x release.

For example, a "from __future__ import print" would need to be added to 2.6 
to allow the use of print-as-function syntax.  Otherwise, there is no way 
to write code that works in 2.x *and* 3.x, because print is a reserved word 
in 2.x, and can't be a statement in 3.x.


>It seems to me preferable to allow repeated translation of 2.X code to 
>working no-fixes-required 3.0. Then the cleanup step is required only when 
>withdrawing support (or development) for 2.X and making the final 
>translation. At that point it would be a one-time task.
>
>Or are you suggesting that users make the change to 3.0 and then backport 
>changes to 2.X where necessary using the older semantics? In either case 
>you end up with two different code bases.

No, I'm saying one code base that runs on both.  The main difference 
between me and James Knight on this is that I'm saying 2.6 or 2.7, he 
wanted 2.5.  I agree with Guido that a 2.5 backward target is unreasonably 
restrictive for 3.0.



More information about the Python-Dev mailing list