Since I have not blogged in a week but don't have anything that warrants a full-blown post I figured I would collect stuff I have been working on together in a single post.
My presentation to VanPyZ on Py3K went well despite the fact a projector couldn't be found. I had to use a whiteboard in the room which was fine, but my handwriting is atrocious so I am amazed people were able to follow me. Gathering up all of the major changes made me realize how overall the language itself is just getting cleaned up for the better. Where pain comes in is through changes to the stdlib. Hopefully we will be able to have reasonable warnings in the stdlib for people so they can have an easier transition.
Pulling together what needs to be done in 2.6 to ease the transition to 3.0 is being collected in a Google spreadsheet. The details of how warnings will work and such has yet to be worked out. I am personally hoping that there are levels of warnings. One for stuff that you need to change (e.g., stdlib changes to using bytes), stuff that you can change syntactically but that 2to3 could do as well (e.g., the new raise/except syntax), and stuff that would normally require a __future__ statement (e.g., print becoming a function). I honestly think the latter is not needed and that a __future__ statement should just be left out in favoring of relying on 2to3. Since stuff like 'print' and 'exec' are syntax they can be detected perfectly and thus changed perfectly. I say the less warnings we have to pile into 2.6 the better.
I have also formally posted PEP 362 to python-dev. Neal Becker said that Boost.Python could use the Signature object and was wondering if PEP 362 was going to be accepted. I subsequently updated the code to work with 3.0a1 (which happens to be both 2.6 and 3.0 compatible without any source code changes). If python-dev happens to reject PEP 362 I will end up releasing the code to PyPI and start a Google Code project for it.
One thing that my PEP 362 work made me realize is how much of a pain it is to be working on stuff for 2.6 right now that have different behavior between 2.6 and 3.0. The issue I ran into is inspect.getargspec(). In 3.0 it raises an exception if the function has keyword-only arguments or annotations; you should use getfullargspec() instead. It would make sense then that if I just added getfullargspec() to 2.6 with dummy values for keyword-only arguments and annotations. But that seems silly since both keyword-only arguments and annotations will be backported. Neither, though, have been backported. Plus Py3K warnings have not been exposed at the Python level yet (it has just been done in a cursory fashion in C code).
I ended up just using getfullargspec when possible, defaulting to getargspec when necessary. Now I have to decide if I want to try to get python-dev to make a decision on how to handle warnings again, backport features to 2.6, or stick with trying to get importlib bootstrapped into 3.0. So much to do. =)
