[Python-Dev] ABCs and MRO

Paul Moore p.f.moore at gmail.com
Mon Mar 2 22:14:52 CET 2009


2009/3/2 Jeffrey Yasskin <jyasskin at gmail.com>:
> I tend to think it's a bug in ABCs. You seem to have thought of
> several possible ways to fix it, and I don't have strong preferences
> between them.

I've discussed ways of fixing simplegeneric, but not of fixing the
issue with ABCs. I'm not sure the ABC "issue" is fixable - after all,
it's by design that ABCs can implement __issubclass__ and "magically"
become superclasses of arbitrary classes as a result.

I'm not happy about fixing simplegeneric, though, as the whole point
was just to expose an existing implementation, because it might be
generally useful. If we start expanding and enhancing it, there are
better implementations already available on PyPI (better in the sense
of having seen real-world use). And if they don't handle ABCs, then
that might indicate that needing to handle ABCs isn't as vital as this
discussion would seem to imply (but I have no real-world data myself
to make such a claim).

> One way to deal with __subclasscheck__ definitions other than
> ABCMeta.__subclasscheck__ would be to make the "someone registered a
> subclass" interface public in addition to the "tell me when someone
> registers a subclass" interface. Then other __subclasscheck__
> definitions could call the "someone registered a subclass" method when
> the class is defined if they want to be usable with generic functions.

I'm not sure I follow this. Can you clarify? My intuition is that *no*
notification hook can deal with ABCs that code arbitrary checks in
their __subclasscheck__ method (so there's no registration involved,
particular classes just "magically" become subclasses).

> You can get something similar to the mro by checking whether ABCs are
> subclasses of each other.

The key point about the MRO is that you get it just from the initial
class, via __mro__. You're not checking if another class is *in* the
MRO, but rather you're *generating* the list of classes in the MRO.

Paul.


More information about the Python-Dev mailing list