> On 10:22 pm, [EMAIL PROTECTED] wrote:
> >On 2/27/07, [EMAIL PROTECTED] <[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?

Uh-huh. ;-)

I wrote two versions of the dict views refactoring. One that turns
d.keys() into list(d.keys()) and d.iterkeys() into iter(d.keys()).
This one is pretty robust except if you have classes that emulate
2.x-style dicts. But it generates ugly code. So I have a
"light-weight" version that leaves d.keys() alone, while turning
d.iterkeys() into d.keys(). This generates prettier code but more
buggy. I probably should have used the heavy-duty one instead.

> 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.

Right, this is my hope for 2.6.

> 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.

Right. You need both.

--Guido van Rossum (home page: http://www.python.org/~guido/)
Python-Dev mailing list

Reply via email to