-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
False positive on 'abstract-method' when extending ABC classes #3098
Comments
Thanks for opening an issue! Right now |
It may as well be a core python issue, too. Even if you don't inherit ABC, you can't instantiate the mixin, so there's not really a clean way to semantically declare your intent. Inheriting ABC does quiet Pycharm's warnings, though, hence that trick. Pycharm seems to use that to understand that the class is intended to be abstract. That does add useless depth to the MRO, though. (Sorry for filing so many issues rapid-fire! Thank you for your triage work.) |
Related to pylint-dev#179 and pylint-dev#3098. Tweaks `utils.class_is_abstract` to not depend purely on the presence of abstract methods, and instead also return True for classes that either explicitly inherit from `abc.ABC`, or explicitly define `abc.ABCMeta` as a metaclass. This means that classes like: class Foo(AbstractParent, ABC): ... class Bar(AbstractParent, metaclass=ABCMeta): ... no longer trigger W0223 (Method is abstract in class ... but is not overriden).
…lass=ABCMeta` as abstract (#3446) Related to #179 and #3098. Tweaks `utils.class_is_abstract` to not depend purely on the presence of abstract methods, and instead also return True for classes that either explicitly inherit from `abc.ABC`, or explicitly define `abc.ABCMeta` as a metaclass. This means that classes like: class Foo(AbstractParent, ABC): ... class Bar(AbstractParent, metaclass=ABCMeta): ... no longer trigger W0223.
Steps to reproduce
Consider this snippet:
The stated purpose of this class would be to create an abstract extension of
Mapping
that provides additional functionality as a "mixin". By deriving fromMapping
we declare our requirement thatself.get
will be present. By inheritingabc.ABC
we stipulate that this class itself cannot be instantiated until all of its abstracted methods are defined.Current behavior
Pylint does not appear to understand the semantic consequences of inheriting from
abc.ABC
:Namely, that we are explicitly stating that this class is itself abstract.
Expected behavior
Pylint will understand that we are implementing an abstract class and not produce these errors.
pylint --version output
The text was updated successfully, but these errors were encountered: