Mark Dickinson <dicki...@gmail.com> added the comment:
[Guido] > Possibly at some point in the future we can switch to using typing.Protocol > [...] Yes, I think there's an interesting wider problem here, that typing.Protocol might be the answer to. For numbers and collections.abc in the std. lib., I'm happy to accept that simply having a method present in the relevant ABC class implicitly makes it a part of the interface (though it would be good if that were clarified somewhere). But in our own code, we've found it convenient to have abc.ABC subclasses that are a combination of interface and convenience base class, with the external interface separated from the convenience methods via the @abstractmethod and @abstractproperty decorators: classes that register with the given ABC subclass must provide all methods marked with those decorators, but the other methods are not considered part of the formal interface, and not used by client code that expects only an object implementing that interface. The alternative to that convenience is to have two classes: a separate purely abstract interface, and a base class implementing that interface that's designed for subclassing. That works too, but it's a bit unwieldy, and it's useful to have the all-in-one option available. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue26680> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
