When I run the next code in all my installed versions of Python 3 (and the equivalent code for PyPy and CPython 2.7):

- Runs OK in CPython 2.7 equivalent code (using `ABCMeta` as meta-class).

- Fails in PyPy and all versions of Python 3.

What are you trying to accomplish that needs an abstract base class?

APIError is not an Exception class, it is a meta-class, and thus it does not match the exception because it is not a *base* class of DriverError (it is DiverError's *meta* class).

Now, it is an interesting question whether we want the try/except statement's behavior to match issubclass, since intuitively we think the except in try except is doing the equivalent of issubclass (it isn't).

I don't know why this works in python2, but the class/meta-class machinery did undergo some significant changes.  So, it is possible that this is in fact a bug (ie: an unintentional change in semantics).  If so, it is also a doc bug, since the try statement docs clear say the expression must evaluate to a base class, and the virtual class (abc) docs *only* mention issubclass and isinstance.

Thinking about this some more my explanation isn't quite clear (because my thinking wasn't quite clear): the problem isn't that APIError isn't *capable* of being a base class; I was wrong when I said it is itself a metaclass.  It is a class that has ABCMeta *as* its metaclass.  The problem is what I said in the second part: that APIError isn't a base class *of DriverError*.  The operant issue is that 'except' isn't doing issubclass, it is looking at the base class list of DriverError, and APIError isn't in it.

I'd have to see your 2.7 code to figure out why that version "works" :)

In Python 2, PyErr_GivenExceptionMatches [1] calls PyObject_IsSubclass. To handle calling __subclasscheck__ in this case, 2.7 (but not 2.6) temporarily increases the recursion limit by 5. For example:

    class CMeta(type):
        def __subclasscheck__(self, other):
            import sys
            print 'recursion limit: %d' % sys.getrecursionlimit()
            frame = sys._getframe(1)
            n = 0
            while frame:
                n += 1
                frame = frame.f_back
            print 'frame: %d' % n
            return True

    class C(Exception):
        __metaclass__ = CMeta

    def f():
        try:
            f()
        except C:
            pass

    >>> sys.getrecursionlimit()
    1000
    >>> f()
    recursion limit: 1005
    frame: 1000
    >>> sys.getrecursionlimit()
    1000

If the recursion limit weren't temporarily increased, then trying to call __subclasscheck__ in the above case would raise another RuntimeError.

In Python 3, PyErr_GivenExceptionMatches [2] instead calls PyType_IsSubtype. See issue 2534. In that issue Antoine's reason for the change is that "otherwise there are some nasty issues with recursion checking". 

[1]: https://hg.python.org/cpython/file/v2.7.10/Python/errors.c#l84
[2]: https://hg.python.org/cpython/file/v3.5.0/Python/errors.c#l166

Thanks ~eryksun, you clarified me in where the error is located and possible patches for it.

We are programming a framework where is very important to do mappings between (1) the API and (2) the drivers layers.

We try to make our code available to both branches of Python (2 and 3).  This case is complex because a logical exception type definition (like "resource not found") is implemented different by disparate API consumer applications (these implementing the drivers), for example `httplib`, `couchdb` or any specific database management system.

So, the API layer have to find a way to uniform disparate exception "fauna" in its definitions at a logical level.

ABCs are the nice solution, only have to work as its conceptual definition said, including exceptions, in all Python versions.

This looks like a duplicate of #12029. The delays on addressing that bug seem to indicate that initially there was a fairly substantial performance cost for all exception handling paths when ABC friendly checking was performed, but that was at least partially due to a bug in those code paths that didn't bypass the ABC machinery in the simple subclass case.

That said, I'm not sure it wouldn't cause other performance regressions (I made a comment to that effect on the original bug).

Josh Rosenberg, you are right, it's a duplication. Sorry I didn't find the issue #12029 before.