Email Re: [Python-projects] pylint: Confused by failed import

On Thursday 09 March à 18:47, Maarten ter Huurne wrote:
> 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.
 
Yep, I guess that's the problem. If you want to test, try to add

        return value

on line 155 of file logilab/astng/manager.py (i.e. at the end of the
file_from_module_name method)

-- 
Sylvain Thénault                               LOGILAB, Paris (France).

http://www.logilab.com   http://www.logilab.fr  http://www.logilab.org