This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Unsupported provider

classification
Title: There is no way of determining which ABCs a class is registered against
Type: enhancement Stage: needs patch
Components: Interpreter Core Versions: Python 3.10, Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: aronacher, eric.araujo, ncoghlan, paul.moore
Priority: normal Keywords:

Created on 2009-03-02 10:37 by paul.moore, last changed 2022-04-11 14:56 by admin.

Messages (6)
msg83011 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2009-03-02 10:36
There is no way to determine the list of classes for which issubclass(C,
x) is true. 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'>)
>>>

This means that ABCs do not play well with the type of introspection
required to implement such features as generic functions - namely
enumeration of the (logical) superclasses of a class.
msg83014 - (view) Author: Armin Ronacher (aronacher) * (Python committer) Date: 2009-03-02 13:11
I don't think this can be solved.  Not only do registered classes not
show up (which could be fixed by providing something like
inspect.getfakemro) but ABCs can also perform duck-type checks.

For example a class with an __iter__ method is an instance of
collections.Iterable or how it's called thanks to the __subclasscheck__
magic method.
msg83015 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2009-03-02 13:14
Good point! So a documentation patch, to the effect that there is no way
of determining which ABCs a given class is an instance of, would be an
appropriate resolution, I guess.
msg83018 - (view) Author: Armin Ronacher (aronacher) * (Python committer) Date: 2009-03-02 13:25
I suppose it would be a good idea to fix part of that problem in Sphinx
(and probably also in pydoc) by adding something like ":implements:
MutableMapping" in the docstring.

So that this is explicitly added to the docstring and conforming tools
can use this documentation hints.

Similar things are currently implemented in Sphinx for ":param:"
":return:" etc.
msg83037 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2009-03-02 21:01
While a complete solution isn't possible, at least supporting querying
of explicit registrations would be an improvement over the status quo
(since an implicit registration can always be turned into an explicit
one, but a registration can't always be turned into inheritance).

For this to work in practice, I believe a PEP would be needed to add a
"subscribe" method to ABCMeta instances - this method would accept two
callbacks, one that was called whenever register() was invoked, and a
second when unregister() was invoked. Generic functions which add ABCs
registered could then subscribe to them and update their type caches
appropriately.
msg136719 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2011-05-24 05:12
This topic came up again on python-ideas:
http://mail.python.org/pipermail/python-ideas/2011-May/010293.html
History
Date User Action Args
2022-04-11 14:56:46adminsetgithub: 49655
2020-11-16 22:31:50iritkatrielsettype: behavior -> enhancement
versions: + Python 3.9, Python 3.10, - Python 3.1, Python 2.7
2011-05-24 05:12:32ncoghlansetmessages: + msg136719
stage: needs patch
2010-02-16 05:42:14eric.araujosetnosy: + eric.araujo
2009-03-02 21:01:18ncoghlansetnosy: + ncoghlan
messages: + msg83037
2009-03-02 13:25:03aronachersetmessages: + msg83018
2009-03-02 13:14:25paul.mooresetmessages: + msg83015
2009-03-02 13:11:34aronachersetnosy: + aronacher
messages: + msg83014
2009-03-02 10:37:00paul.moorecreate