It doesn’t actually make any panda specific changes if this is what you mean. lib2to3 does most of the work, I simply tap into its interface and add a second layer of changes for cases specific to compatibility issues between python 2 and 3 (since lib2to3 isn’t intended for this.) The panda codebase can be maintained and modified in python 2 with the script being used to generate python 3 snapshots on the fly. Once the script itself is ironed out and working, changes to panda source shouldn’t introduce any new issues (unless someone uses a particularly archaic language feature.)
It logs every change so any errors introduced can be found quickly. That’s basically how I’ve been testing it: working to failure, finding the change that made the failure, and then making a custom fix for that case to make it work in both versions of python. When the script is rerun it takes care of all those cases wherever it finds them. Library name changes would be an example:
# this
from StringIO import StringIO
# becomes:
if PY_VER < 3: from StringIO import StringIO
else: from io import StringIOIt makes the resulting code a bit messier, but doesn’t introduce any errors by itself. I’ll just continue testing the results against my 2.7 panda using as much functionality as I can figure out. I think some kind of unit testing would be essential in the end though… python has a large unit testing library so I’ll start looking into that when/if it becomes relevant. Here’s some stats output from a basic run over the direct, pandac, and examples folders, it shows how many changes it actually makes:
panda_to_py3: 163.796875 seconds
dirs: 104
files: 460
lines read: 130033
lines fixed: 3258
lines added: 417