Author mark.dickinson
Recipients Austin Bingham, christian.heimes, gvanrossum, mark.dickinson, rhettinger, robert_smallshire, serhiy.storchaka, tim.peters
Date 2020-10-05.09:00:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1601888429.08.0.113280510381.issue26680@roundup.psfhosted.org>
In-reply-to
Content
[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.
History
Date User Action Args
2020-10-05 09:00:29mark.dickinsonsetrecipients: + mark.dickinson, gvanrossum, tim.peters, rhettinger, christian.heimes, serhiy.storchaka, robert_smallshire, Austin Bingham
2020-10-05 09:00:29mark.dickinsonsetmessageid: <1601888429.08.0.113280510381.issue26680@roundup.psfhosted.org>
2020-10-05 09:00:29mark.dickinsonlinkissue26680 messages
2020-10-05 09:00:28mark.dickinsoncreate