On Tue, Oct 01, 2019 at 09:47:56AM -0700, Andrew Barnert via Python-ideas wrote: > On Oct 1, 2019, at 06:23, Richard Musil <risa20...@gmail.com> wrote: > > > > Where *virtual* is a hyperlink to an ABC definition. > > > > `issubclass` will be fine without virtual and I am not sure why > > virtual has been added to it > > Virtual subclassing is key to the way ABCs work.
Virtual subclassing is the key to the way ABCs work *in Python*, which means we could have designed them differently had we chosen to. In Python, ABCs combine the notions of *abstract* classes with virtual subclassing via registration. But we could have made them more like "abstract" in C++ and C# and required actual inheritence. In fact, Python ABCs also include the notion of *interface testing* and mixins so they really conflate FIVE orthogonal but related concepts into one: - the notion of abstract classes (which cannot be instantiated) and abstract methods (which must be overridden); - mixins for default implementations of certain common operations; - inheritence and nominal subtyping, where one class is included in the MRO of another class; - virtual subclassing using registration; - and protocol or interface testing (duck typing). Aside from the first two, they involve three independent notions of subtyping: - if I inherit from a duck, I am a duck; - if I say I am a duck, I am a duck; - if I quack like a duck and swim like a duck, I am a duck; and being independent, we can construct examples where they conflict. If I inherit from a duck, but say I'm a goose, and honk rather than quack, what am I? I don't wish to get into a debate over whether Python's design is good, bad or indifferent. Whatever the reasons, ABCs as defined in the abc and collections.abc modules are what we have to live with, and I'm not proposing any change to that. Nor am I proposing the addition of a dozen new ABCs. If anyone wants to redesign Python's ABCs and interface-testing, please write a PEP and don't hijack this thread :-) All I'm proposing is one tiny but useful change, the addition of a single ABC for testing whether or not an object quacks like something subscriptable, akin to five existing ABCs: - Callable tests for __call__ - Container tests for __contains__ - Hashable tests for __hash__ - Iterable tests for __iter__ - Sized tests for __len__ Nor am I proposing to change the way we test for these dunder methods. The current implementation tests for the existence of an *attribute* of that name on the class or a superclass, whether it is callable or not, so long as it is not None. That is a private implementation detail of the collections.abc module. If anyone wants to change the implemention of that test, please start a new thread and don't hijack this one :-) -- Steven _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OGMTYDFXB22MRATAXBVITBG5GIJPVJ7C/ Code of Conduct: http://python.org/psf/codeofconduct/
