pylint bug - E1101 & E0102 upon use of @property + @foo.setter

Question

I noticed pylint doesn't handle well the case of:

@property
def foo(self):
   return self._bar.foo

@foo.setter
def foo(self, foo_val):
   self._bar.foo = foo_val

Though it's a perfectly valid case syntax since python2.6

It says I defined foo twice, and doesn't understand the ".setter" syntax (Gives E1101 & E0102).

Is there a workaround for that without having to change the code? I don't want to disable the errors as they are important for other places.

Is there any other tool I can use that handles it better? I already checked pyflakes and it behaves the same way. PyDev's code analysis seems to handle this specific case better, but it doesn't check for conventions, refactoring, and other cool features pylint does, and I can't run it from an external script (or can I??)

Thanks!

Tenaculum

Answer 1

This is ticket http://www.logilab.org/ticket/51222 on the pylint project. Monitor it's status.

Swordfish

Answer 2

If you don't want to disable the errors globally, you can disable them for these specific lines, for example:

def foo(self, foo_val): # pylint: disable-msg=E0102

Zobias

Answer 3

Huh. Annoying. And all the major tools I could find (pyflakes, pylint, pychecker) exhibit this problem. It looks like the problem starts in the byte code, but I can't get dis to give me any byte code for object properties.

It looks like you would be better off if you used this syntax:

# Changed to longer member names to reduce pylint grousing
class HughClass(object):
    def __init__(self, init_value):
        self._hugh = init_value
    def hugh_setter(self):
        return self._hugh * 2
    def hugh_getter(self, value):
        self._hugh = value / 2
    hugh = property(hugh_getter, hugh_setter)

Here's a nice blog article on it. LOL-quote:

Getters and setters belong to the sad world of Java and C++.

Nainsook

:( this is what i was afraid of - I would prefer not having to change existing code. But I agree this looks better anyhow. – Tenaculum

Well, then you can add # pylint comments, as @Zobias suggests, to selectively disable the complaints. – Nainsook

Message from 8 years in the future after this answer was posted: In current python, this syntax is vastly inferior to that as shown in the question. Perhaps there should be an edit explaining to not use this syntax anymore ? – Grilled

@JaccovanDorp, I wouldn't be too quick on that. I just raised this question, #53598874 and this syntax seems to make the problem go away – Marchese

See my answer there for details – Grilled

Answer 4

This was reported as a bug in pyflakes, and it appears to be fixed in current trunk. So I guess the answer (now) is: pyflakes!

Lakeshialakey