frans frans - 11 months ago 67
Python Question

Avoid Pylint warning E1101: 'Instance of .. has no .. member' for class with dynamic attributes

Imagine a function which dynamically adds attributes to an object using

. The reason for doing so is that I want to map some external structure (e.g. a given parameter tree) to an object:

my_object = SomeClass()
apply_structure(my_object, some_descriptor)
my_object.device1.enabled = True

Technically this works but of course Pylint rightly complains about 'device1' being not a member of

I could disable the warning but that would be bad (because I still want to get the warning in all cases when the attribute does not exist because of misspelling, etc).

Is there a common and legal (Pylint-proof) way to dynamically add members to an object that not leads to warnings?

Alternatively: Can I disable Pylint for just one object rather than a line/block/file?


You might wonder why I should equip an object with member attributes dynamically when I plan to access these attributes in a hard-coded way later.

The reason is: I have a dynamic part of the program (where the decoration happens) and a static part which is specialized for a certain scenario. So I could also create a static class for this scenario but that would be overkill in a lot of situations.

The following specialized code might allow access to some parameter of a device which might be attached to some bus:

class MyDeviceHandler:
return _some_internal_value
on_set_some_subtree_element(self, value):
_some_internal_value = value

dev = MyDeviceHandler()

decorate_object_with_device_structure(dev, 'some/attached/device')

dev.some.subtree.element = 5 <--- will call the set-callback
x = dev.some.subtree.element <--- will call the get-callback

So the structure behind
might be arbitrary and very complex and I don't want to reproduce it in a class structure.

One way to get rid of this warning would be to create/access a
based tree:

dev['some']['subtree']['element'] = 5

But this is harder to write and not nice to read - I would only do this to quieten Pylint.


Just to provide the answer that works for me now - as The Compiler suggested you can add a rule for the problematic class in your projects .pylintrc: