[Python-3000] Strategy for porting to 3.0?

Eric Smith eric+python-dev at trueblade.com
Wed Mar 19 15:25:50 CET 2008


skip at pobox.com wrote:
>     Martin> One option that I envision is that you might keep all sources as
>     Martin> 2.x, and only convert to 3.x at installation time, 
> 
> How can this ever work?  Aren't there always going to be some
> incompatibilities which aren't covered by -3 or 2to3?  Those will require
> manual code changes which aren't 2.x compatible.

I've always thought that yes, there will some things that 2to3 doesn't 
(or can't) fix, but it should be possible to modify your 2.x code so 
that you don't trigger these issues.  Then you'll end up with code that 
can in fact fun in 2.x and in 3.x by way of 2to3.

For example, say that 2to3 changes all instances of has_key to an "in" 
expression (I'm not saying it does this or not, I really don't know). 
If you have a Locksmith class that has a has_key method unrelated to 
dicts, then 2to3 would break it.  But it's certainly possible that you 
could change the method name in your 2.6 code and avoid the problem. 
You'd have 2.6 code that could automatically run in 3.0.

This won't work with public API's that can't be changed, but I think 
it's a valid strategy for most code.

The proposed 3to2 also might be a way out.

Eric.


More information about the Python-3000 mailing list