Bug 127243 - can't stop pychecker from checking system Python modules
Summary: can't stop pychecker from checking system Python modules
Alias: None
Product: Fedora
Classification: Fedora
Component: python   
(Show other bugs)
Version: 2
Hardware: All Linux
Target Milestone: ---
Assignee: Mihai Ibanescu
QA Contact: Brock Organ
Depends On:
Blocks: 131439
TreeView+ depends on / blocked
Reported: 2004-07-05 05:02 UTC by Chris Siebenmann
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-20 19:59:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Use (make install DESTDIR=...) instead of (%makeinstall DESTDIR=/) (739 bytes, patch)
2004-10-11 12:30 UTC, Miloslav Trmač
no flags Details | Diff

Description Chris Siebenmann 2004-07-05 05:02:25 UTC
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):

How reproducible:

Steps to Reproduce:
1. Create a sample module:
 $ cat testmodule.py
 import HTMLParser
 class T(HTMLParser.HTMLParser):
  def handle_starttag(self, tag, attrs):
   print tag, attrs
 def test(string):
   __pychecker__ = "no-abstract"
   t = T()

2. Run pychecker on it with the appropriate option.
 $ pychecker --stdlib testmodule
Actual results:
 A cascade of complaints about HTMLParser.py and markupbase.py,
both of which are standard modules.

Expected results:

 No complaints.

Additional info:

 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.

Comment 1 Miloslav Trmač 2004-10-06 22:18:40 UTC
The files containing buildroot paths are from the python package
(still there in python-2.3.4-10).

Comment 2 Miloslav Trmač 2004-10-11 12:30:22 UTC
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.

Comment 3 Miloslav Trmač 2005-02-04 14:16:21 UTC
This is fixed in python-2.3.4-13 (FC3 update).

Note You need to log in before you can comment on or make changes to this bug.