On 10:22 pm, [EMAIL PROTECTED] wrote:
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.

Actually, this did happen with the iterkeys -> keys translation. A few
unittests were reduced to pure nonsense by this. Most of those failed,
but it was definitely a hassle finding out what went wrong (in part
because I was too greedy and checked in a bunch of converted code
without any review at all). Lesson learned I would say. Fortunately,
this is a case where 2.6's Py3k warning mode should compensate.

Was this due to a bug that can be fixed, or an inherent problem?

I could imagine, thanks to Python's dynamism, there would be edge cases that are impossible to detect completely reliably. If that's the case it would be good to at least have pedantic warnings from 2to3 alerting the user to places where translation could possibly be doing something semantically dodgy.

Ideally before jumping the chasm with Twisted I'd like to make sure that all of that sort of warning was gone, in _addition_ to a clean test run.
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.

I'm hoping Collin will continue his excellent work on 2to3. Hopefully
he'll get help from others in writing docs aimed at teaching the
c.l.py crowd how to use it and what to expect.

I'm sure he'll hear from me if anything goes wrong with it :).
Thanks *very* much to all the python core developers and community members who have been working to make this happen, especially to Neal, Thomas, and Guido for listening intently to all of our concerns at PyCon.

You're welcome. I believe I even got a beer out of it. ;-)

Well deserved!
Python-Dev mailing list

Reply via email to