This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 127243 - can't stop pychecker from checking system Python modules
can't stop pychecker from checking system Python modules
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: python (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mihai Ibanescu
Brock Organ
:
Depends On:
Blocks: 131439
  Show dependency treegraph
 
Reported: 2004-07-05 01:02 EDT by Chris Siebenmann
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-20 15:59:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Chris Siebenmann 2004-07-05 01:02:25 EDT
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
.pycheckrc.

Version-Release number of selected component (if applicable):
pychecker-0.8.13-3

How reproducible:
Always.

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()
   T.feed(string)
   T.close()

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
location.

 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 18:18:40 EDT
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 08:30:22 EDT
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 09:16:21 EST
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.