[Python-projects] __init__ method from a non direct base class <logilab.astng.Yes object at 0xb7f8392c> is called

[Sylvain Thénault]

On Tuesday 21 November à 12:34, Barry Scott wrote:
> Sylvain Thénault wrote:
> >
> >>I get around 200 errors out of the first module that I run pylint on. I 
> >>cannot release
> >>this source for you to test against. I will have to build a smaller 
> >>example
> >>that breaks otherwise we will have nothing concrete to work with.
> >>
> >>My first attempt at a small example did not have the problem with this 
> >>class.
> >>However when I forgot to copy a __init__.py I did see the message:
> >>
> >>__init__ method from a non direct base class    <logilab.astng.Yes 
> >>object at 0xb7f8392c> is called
> >>
> >>So a missing __init__.py is another way to get this message.
> >>
> >>Am I right in guessing that this message means pylint/ast failed to find 
> >>information? Is it
> >>a place holder in the code?
> >>    
> >
> >you're right, and the easiest way to get ride of W0233 false positive is
> >to skip YES object where this message is issued, as done by the patch
> >below. Getting warning for inference problem is harder since this
> >problem is tied to astng which shouldn't contain pylint specific code.
> >I plan to use the logging module at some point to allow astng > pylint
> >communication, but this is really not a priority for me at least, so...
> >
> >diff -r a6d5c4daf255 checkers/classes.py
> >--- a/checkers/classes.py       Wed Nov 15 19:43:01 2006 +0100
> >+++ b/checkers/classes.py       Mon Nov 20 16:47:00 2006 +0100
> >@@ -442,6 +440,8 @@ instance attributes.'}
> >                 return
> >             try:
> >                 klass = expr.expr.infer().next()
> >+                if klass is astng.YES:
> >+                    continue
> >                 try:
> >                     del to_call[klass]
> >                 except KeyError:
> >
> >  
> This is a bad idea right? At least with the __init__ message I now know 
> why the
> following "method not defined" messages occur.
> 
> The problem is that because of the failure to find out about base 
> classes there are huge
> number of false positive messages.

you mean that with this patch applied you get some other false positive?
 
> I'll try and track down why astng cannot find out about my imports. BTW 
> pychecker
> has no problem finding the imports and reporting on problems with them. 
> Whatever
> the root cause is it is subtle.

See Skip's post for more detail on the different approach between pychecker 
and pylint.
 
> If the only time a YES object is create is when a failure to find 
> happens then I should
> be able to raise an exception in the __init__ of YES and try an figure 
> out why YES is
> being created. Does that sound like a reasonable way to focus in on the 
> underly cause?

that won't be that easier since :
* the YES object is a singleton only instancied once
* a YES object is returned on every inference failure on an inference
  path. That means that for instance when looking for the object on
  which a method is called, you could get the actual object *and* a YES
  object if another path has failed

> My hope is that pylint will  be able to find the problems that pychecker 
> is missing.

That's my hope too. And much more of course ;)

-- 
Sylvain Thénault                               LOGILAB, Paris (France)
Formations Python, Zope, Plone, Debian:  http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
Python et calcul scientifique:           http://www.logilab.fr/science