from
Maarten ter Huurne <maarten.ter.huurne at philips dot com>
to
Sylvain Thénault <sylvain.thenault at logilab dot fr>
cc
Python-Projects <python-projects at lists dot logilab dot org>
subject
Re: [Python-projects] pylint: Confused by failed import
date
2006/03/09 18:47
syt@logilab.fr wrote on 2006-03-09 06:36:59 PM:
> > > > === super.py:
> > > > import this_module_does_not_exist
> > > >
> > > > class Super(object):
> > > > def inherited_method(self):
> > > > pass
> > > > === sub.py:
> > > > from super import Super
> > > >
> > > > class Sub(Super):
> > > > def some_method(self):
> > > > self.inherited_method()
> > > > ===
> >
> > I don't really understand this problem...
> >
> > There is no missing information in the module that could not be imported:
> > if this import is removed, everything is fine. So it seems that pylint is
> > not using any definitions from "super.py" because of the failed import. If
> > it would just report and then ignore the failed import, it should be able
> > to avoid issuing the error. Or am I overlooking something?
>
> As I understand it, the problem is that the "inherited_method" is
> defined in super.py so when pylint try to guess where the
> "inherited_method" is coming from when it's called in a Sub method, it just
> fails if it doesn't find the super module and so report a missing
> attribute problem.
Ah, but that is not actually the case here. The "super" module can be found, but contains an invalid import itself.
In other words, "from super import Super" will fail when this code is executed by CPython not because "super.py" does not exist, but because during the execution of the body of "super.py" another import fails, namely the import of "this_module_does_not_exist". But for pylint this should not be an issue, as it can simply report that "this_module_does_not_exist" cannot be found and still process the rest of "super.py".
Maybe this is related to the import bug of astng 0.15.0? If "super.py" is imported into the CPython VM running pylint instead of being parsed by astng, that would explain the behaviour I'm seeing. If so, this false positive should be gone when using astng 0.15.1.
Bye,
Maarten