Present Perfect

The first PyChecker release done by yours truly is out the door. You can download the source or install the Fedora 12/13/14 package from my package repository. I hope to push it in Fedora as soon as possible.

This release collects two years of bug fixes, and adds support for Python 2.7, which is now the default in Fedora 14.

I already have a few additional local patches that bring out a bunch of new (and correct) warnings in Flumotion, so I'll probably not wait another two years for the next release. My goal is to work towards a clean check of Flumotion.

The first PyChecker release done by yours truly is out the door. You can download the source or install the Fedora 12/13/14 package from my package repository. I hope to...

After more than two years, it's high time another PyChecker release is made. The previous stable release, 0.8.18, does not work at all with Python 2.7. I also implemented a slew of opcodes, and I fixed one particular bug a long time ago where modules with the same name (in different packages) where hiding each other's errors. Especially in Flumotion where most components have an admin_gtk.py, this was very common.

This is going to be my first PyChecker release, so I would appreciate it if you could give this prerelease a whirl and see how it works for you. I'm especially interested in hearing from projects that used to use pychecker but have stopped using it because it hasn't seen releases the past years.

Download the pre-release. The same directory has a src.rpm and a noarch.rpm for Fedora 14.

I plan to release this Saturday.

After more than two years, it's high time another PyChecker release is made. The previous stable release, 0.8.18, does not work at all with Python 2.7. I also implemented a...

... went a little something like this.

• home desktop upgraded to F14, still a bunch of packages missing.
• Want to do a release of moap because it's been too long, but can't because make check fails because pychecker fails because F14 is the first one with Python 2.7
• Look into pychecker failures. Figure out that there are new opcodes. Worse - for the first time I can tell opcode numbers have been shifted around. Find this bug where renumbering started; commented to ask if this was expected. Apparently it is, although no good reason for doing so has been offered. Shrug, not my fight, although it's going to make for ugly if's in Pychecker code.
• Realize I don't actually have Python 2.7 on the Pychecker buildbot page. Remember I have a script to build Python versions from source which now builds 2.3-2.7 and 3.0 (just check out and run make, then py-x.y to start a shell with that version of python).
• Add it to buildbot master config, restart, see buildbot fail spectacularly. Apparently buildbot was upgraded since I last started it, and code has been shuffled around. Spend a few hours figuring out how to upgrade buildbot and my code with custom steps without losing the history. Now have a buildbot 0.7.12 building on 2.7 as well.
• Add some ugly if's for python versions to handle opcode reshuffling. Brings down the test failures. Add some handlers for new things like POP_JUMP_IF_TRUE/FALSE and JUMP_IF_TRUE/FALSE_OR_POP. End up with only one test failure difference with 2.6
• Look into the remaining failure, realize that it is checking for constness of return results, and JUMP_IF_TRUE/POP_TOP pairs are now POP_JUMP_IF_TRUE, so peeking ahead to see LOAD_CONST should move by one opcode.

So, yay! That means CVS (yes...) HEAD of pychecker now works just as good for 2.7 as 2.6 and it's time to start releasing somewhere this week. And maybe I should push on and fix some of the older failures, or shelve them for now, while I'm at it, and have nicely green builds!

... went a little something like this. home desktop upgraded to F14, still a bunch of packages missing. Want to do a release of moap because it's been too long,...