Red Hat Bugzilla – Bug 127243
can't stop pychecker from checking system Python modules
Last modified: 2007-11-30 17:10:45 EST
Description of problem:
Pychecker has an option not to complain about potential problems
that are in the system library (-q / --stdlib on the command line,
'ignoreStandardLibrary' in .pycheckrc). This option does not work
on Fedora Core 2.
Similar results happen if you attempt to exclude specific
standard modules by manipulating the 'blacklist' variable in
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a sample module:
$ cat testmodule.py
def handle_starttag(self, tag, attrs):
print tag, attrs
__pychecker__ = "no-abstract"
t = T()
2. Run pychecker on it with the appropriate option.
$ pychecker --stdlib testmodule
A cascade of complaints about HTMLParser.py and markupbase.py,
both of which are standard modules.
The core of the problem can be seen in the odd paths that pychecker
attributes to the HTMLParser and markupbase modules. Pychecker works
with the co_filename element of code objects; in .pyc and .pyo files,
this has its value set (to the original name of the file) at the time
when they are compiled to bytecode. Because of the RPM build process,
their location at the time of compilation is nothing like their final
Because of this difference between the file location embedded into
the .pyc/.pyo files and the actual system location, Pychecker thinks
that all of the .pyc / .pyo files of system Python modules are not
actually system Python modules, so --stdlib does nothing.
A similar problem applies to the 'blacklist' .pycheckrc variable
because Pychecker actually excludes blacklisted modules based on
the full module paths. When it gets the module path right, it will
consequently fail all comparisons against the co_filename values.
The files containing buildroot paths are from the python package
(still there in python-2.3.4-10).
Created attachment 105005 [details]
Use (make install DESTDIR=...) instead of (%makeinstall DESTDIR=/)
This should fix it.
The 2.2-0.9b2 changelog comment suggests that distutils would be confused,
but comparing the pre-patch and post-patch buildroots, the only differences
are in *.so* and *.py[co] and /usr/lib/python*/distutils* contains no
*.so* files, so AFAICS distutils should not be affected.
This is fixed in python-2.3.4-13 (FC3 update).