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

[Barry Scott]

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.

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.

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?

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

Barry