pychecker and modules with the same name |
2008-07-14
|
It took a lot more work than I expected, but I finally integrated the last of my pychecker patches into CVS just now.
This was a rather embarassing bug where pychecker would 'forget' about all warnings for A/C.py and B/C.py just because both files pretend to be a module called 'C' and pychecker was using sys.modules as a base for tracking stuff. Since pychecker imports all file arguments as a toplevel module, this clashes.
I created a unittest-based testsuite for pychecker, added a test for this particular case, then integrated my previous patch. I ran into an annoying problem though - some other tests now failed from the old testsuite.
Turns out that the code that checks if subclasses call up to superclass __init__ methods was using sys.modules to get to the code object and see if it was called. Since my patch now cleans up sys.modules from all these ad-hoc modules for the file arguments, this wasn't working anymore.
So I created a new module in pychecker to track all PyCheckerModule objects, and use that instead. They're tracked by module name and directory that module name can be loaded from.
It took a while originally before I realized pychecker had this bug - in Flumotion we have a lot of similarly-named files for different components, for example admin_gtk.py
PyChecker never caught any bug in these until I figured this bug out and created a patch.
So, I think I have now integrated all my 2 year old patches for pychecker, just in time for Neal's tentative code freeze. Yes, pychecker is actually going to get a release very soon! No more building custom packages for our contributors.
I'll leave the final testing for tomorrow.