Andrew Barnert
2014-07-25 20:46:29 UTC
An ABC built with abc.ABCMeta has a member __abstractmethods__, which is an iterable of all of the abstract methods defined in that ABC that need to be overridden. A method decorated with @abstractmethod gets a member __isabstractmethod__=True, which is how the ABC (or, rather, the interpreter) checks whether each of its abstract methods have been overridden.
However, they're part of a private protocol used by the CPython implementation of the abc module, which means any third-party code that uses them isn't portable or future-proof. Which is a shame, because there are all kinds of things you can build easily on top of abc with them, but would have to duplicate most of the module (and the special interpreter support for it) without them.
The simplest change is just to document these two members as part of the module interface.
Alternatively, there could be functions abc.isabstractmethod(method) and abc.abstractmethods(cls), which would allow for implementations that didn't use the same protocol internally but supported the same interface.
Examples where this could be useful:
* Write a runtime check-and-register function.
* Explicitly test that a set of classes have implemented their ABC(s) without having to know how to correctly instantiate them.
* Write a generic @autoabc decorator or similar for creating ABCs that are automatically virtual base classes of any type with the right methods, instead of doing it manually in each class (as collections.abc does today), like Go interfaces, C++ auto concepts, traditional ObjC checked informal protocols, etc.).
* Build a signature-checking (rather than just name-checking) ABC (like https://github.com/apieum/ducktype).
* Build a simplified version of PyProtocols-like adapters on top of abc instead of PyProtocols.
Some of these might belong in the stdlib (in fact, it looks like http://bugs.python.org/issue9731 basically covers the first two), in which case they don't need to be implementable from outside… but that's certainly not true for all of them. (Without a precise algorithm for "compatible signature" or a standardized notion of adaptation, stdlib inclusion isn't even sensible for the last two, much less a good idea.) So, outside libraries should be able to implement them.
However, they're part of a private protocol used by the CPython implementation of the abc module, which means any third-party code that uses them isn't portable or future-proof. Which is a shame, because there are all kinds of things you can build easily on top of abc with them, but would have to duplicate most of the module (and the special interpreter support for it) without them.
The simplest change is just to document these two members as part of the module interface.
Alternatively, there could be functions abc.isabstractmethod(method) and abc.abstractmethods(cls), which would allow for implementations that didn't use the same protocol internally but supported the same interface.
Examples where this could be useful:
* Write a runtime check-and-register function.
* Explicitly test that a set of classes have implemented their ABC(s) without having to know how to correctly instantiate them.
* Write a generic @autoabc decorator or similar for creating ABCs that are automatically virtual base classes of any type with the right methods, instead of doing it manually in each class (as collections.abc does today), like Go interfaces, C++ auto concepts, traditional ObjC checked informal protocols, etc.).
* Build a signature-checking (rather than just name-checking) ABC (like https://github.com/apieum/ducktype).
* Build a simplified version of PyProtocols-like adapters on top of abc instead of PyProtocols.
Some of these might belong in the stdlib (in fact, it looks like http://bugs.python.org/issue9731 basically covers the first two), in which case they don't need to be implementable from outside… but that's certainly not true for all of them. (Without a precise algorithm for "compatible signature" or a standardized notion of adaptation, stdlib inclusion isn't even sensible for the last two, much less a good idea.) So, outside libraries should be able to implement them.