What does this PyChecker warning mean?

[Leo Breebaart]

When fed the following code:

def Foo():

class A(object):
def __init__(self):
pass

class B(object):
def __init__(self):
pass

PyChecker 0.8.18 warns:

foo.py:9: Redefining attribute (__init__) original line (5)

I do not understand what is meant by this warning. In fact, it
simply seems wrong -- but I have learned not to jump to that
conclusion too quickly, so I was hoping someone here could
perhaps enlighten me...

Many thanks in advance,

 

[Peter Otten]

When fed the following code:

def Foo():

class A(object):
def __init__(self):
pass

class B(object):
def __init__(self):
pass

PyChecker 0.8.18 warns:

foo.py:9: Redefining attribute (__init__) original line (5)

I do not understand what is meant by this warning. In fact, it
simply seems wrong -- but I have learned not to jump to that
conclusion too quickly, so I was hoping someone here could
perhaps enlighten me...

You are right, that's a false positive. pychecker seems to confuse the
namespaces.

Peter

 

[Steven W. Orr]

On 1 June 2010 21:48, Leo Breebaart <[email protected]


When fed the following code:

def Foo():

class A(object):
def __init__(self):
pass

class B(object):
def __init__(self):
pass

PyChecker 0.8.18 warns:

foo.py:9: Redefining attribute (__init__) original line (5)


Out of curiosity, why are you defining two classes inside a function?

-Xav

In terms of constructing a minimal example, Foo might be fodder for a closure
that either returns A or B. Just s stab in the dark...


--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net

 

[Leo Breebaart]

Not my code! Not my code!

This code was contributed by someone else, and I merely took my
default action (in such cases) of running pyflakes, pychecker,
and pylint on it before doing anything else, just to see what
comes up.

As far as I can tell the sole reason for that code being
structured the way it is, is to provide a kind of
module-within-a-module and not clutter up the outer module with
these helper classes needed only by the foo() function.

 

[Terry Reedy]

You are right, that's a false positive. pychecker seems to confuse the
namespaces.

Consider sending this example back to the pychecker author.
The program does not seem to be interpreting the nested class statements
properly.

 

[MrJean1]

Although PyChecker 0.8.18 is quite an improvement over previous
releases, it does have quirks. The PyChecker postprocessor might be
helpful, see

<http://code.activestate.com/recipes/546532/>

/Jean