[Python-Dev] ABCs and MRO

[Paul Moore]

2009/3/2 Benjamin Peterson <benjamin at python.org>:
> 2009/3/1 Paul Moore <p.f.moore at gmail.com>:
>>
>> Is it worth getting simplegeneric exposed in 3.1
>> (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd
>> like to see it hit 3.1. The patch is against trunk (for 2.7) at the
>> moment, I'm not sure what the process would be for forward-porting it
>> (do I generate a new patch against the py3k branch, or should it be
>> applied to trunk and merged in?)
>
> Patches to the trunk are fine.

OK, thanks.

> As for the actual feature, I don't think it should hold up releases.

Fair enough.

The key problem with the patch is that ABCs do not play well with the
type of introspection required to implement a generic function -
namely enumeration of the superclasses of a class. The MRO of the
class is fine for normal inheritance, but for ABCs it is possible to
register classes which don't inherit from the ABC, so that you have a
situation where issubclass (C, MyABC) can be true without MyABC being
in C.__mro__:

>>> import abc
>>> class MyABC(object):
...     __metaclass__ = abc.ABCMeta
...
>>> class C(object):
...     pass
...
>>> MyABC.register(C)
>>> issubclass(C, MyABC)
True
>>> C.__mro__
(<class '__main__.C'>, <type 'object'>)
>>>

More generally, there is NO WAY to determine the list of classes for
which issubclass(C, x) is true.

This could be considered a limitation of, or a bug in, ABCs, I don't
have a particular opinion on that, but it does mean that no code which
relies on being able to traverse the class inheritance graph will see
ABCs. One particular case of this is (any implementation I can think
of, of) generic functions.

In my view, this implies one of the following:

1) It should be a documented limitation of such code that it doesn't
work with ABCs (and conversely, this limitation of ABCs should be
documented in the ABC documentation)
2) Generic functions, and any other code requiring this type of
introspection, is essentially useless unless it can support ABCs, and
should not be used in the light of this limitation.
3) This is a bug in ABCs and should be fixed.
4) Something else I didn't think of :-)

In my view, (2) is an unreasonable position to take, given the fact
that (as I understand it) ABCs are supposed to be largely optional and
shouldn't affect code that doesn't care about them...

It's not clear to me how (3) should be addressed. Adding a slot to all
classes to hold a list of ABCs they are registered against seems to be
a large overhead for a relatively rarely used feature. I guess having
a global registry of ABC registrations could work, but it seems
clumsy. Any other suggestions?

The problem with (1) is that it simply acknowledges the issue, but
doesn't actually fix it. Nick Coghlan has commented (in the tracker)
that he feels that the limitation is significant (enough to push him
from +1 to -0 on the feature).

I have created an issue in the tracker -
http://bugs.python.org/issue5405. In my view, it's fairly critical,
but I've refrained from setting a high priority as that may just be my
vested interest talking :-)

I'd appreciate it if someone could comment (either here or on the
tracker item) on what the correct way forward should be. If the answer
is "fix the ABC bug", then I'll have a look but I'm not sure if I can
do it without help - any assistance would be appreciated.

Paul.