> 2to3 should take great care _tell_ you when it fails.  One concern I have is 
> that the
> source translation may subtly alter the *semantics* of unit test code, so 
> that the tests
> are no longer effective and do not provide adequate coverage.  I think this 
> is an
> extremely unlikely edge case, but a very dangerous one in the event that it 
> does
> happen.  I don't know of any bugs in 2to3 that will do this at the moment, 
> but then it's
> hardly the final release.

We're trying hard to avoid semantic changes, and anywhere that
semantic changes might be introduced, 2to3 will throw up all kinds of
warning messages. 2to3 generally tries to limit itself to safe,
syntax-only changes ("apply(f, v, k)" -> "(f)(*v, **k)"), though there
are pathological cases where even that could go astray ("d.has_key(k)"
-> "k in d", where d.has_key() and d.__contains__ differ).

2to3 should be approached as a conversion guide, not as a converter itself.

> Also, the limitations of 2to3 should be very well documented, so that when it 
> does tell
> you how it has failed, it's clear to the developer what changes to make to 
> the *2.6
> source* to cause it to translate correctly, not how to fix up the translated 
> 3.0 code.

This is something I'm working on at the moment, compiling a list of
"things 2to3 can't catch". Some are obvious (m = d.has_key; if m(k):
...), others less so ("raise E, V" where V is an exception instance).
We're hoping that 2to3 will be able to convert 90% of Python 2.x
automatically and offer a solid, step-by-step plan for manually
recoding the remaining 10%.

Collin Winter
Python-Dev mailing list

Reply via email to