Today, I start hunting down native Python 3 code to test out lib3to2. It’s quite a bit earlier than the midterm evaluation, which was my target date to start this, but I don’t think that anything else I could do in the meantime would have a better impact than this.
For the next week, I will be searching for Python 3 code, running 3to2 on it and testing both versions to try and find as many lib3to2 bugs as possible. Unless the fix is obvious and quick, each bug will go into the tracker and a test case will be written. This accomplishes a few things:
- Most obviously, it seems like the best way to find lib3to2 bugs, including failure to warn when a fix is not made.
- Filling up the tracker seems to me like the best way to document what works and what does not.
- Less subtly, this will help figure out the popularity of certain Python idioms that are prohibitively difficult to refactor with lib3to2, such as “from urllib import request”. If it seems like every single large package uses such an idiom, it might be worth it to re-evaluate the decision not to refactor that.
As an aside, I consider anything not fixed that emits a proper, descriptive message not to be a lib3to2 bug. If a fix would be possible within the framework of the lib2to3 API, then it could be considered for an “enhancement” entry on the tracker. I’ve probably written that before, but it is relevant here again.
I’ll start with the Python 3 standard library, then work my way to PyPI, then I’ll do some Google Code Searching.