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.