>> Isn't it just a limitation?
>> Most Python-implemented objects supports weakref. I don't think "requiring weakref support implies it must be type object".

> Formally, there is no implication. It is the abc module authors who know the truth. But I can't imagine why anybody would impose such a limitation by design, because while instances of user-defined classes support weakrefs, built-in classes used by everybody like tuple, list and dict don't. That's why I guessed that non-types were not meant to be supported.

Of course, issubclass(42, AnyABC) must raise TypeError.  They aren't class-like object. I didn't discuss on it.

I talked about class-like objects.
For example, this code works on Python 3.6, but not on 3.7.  typing.Mapping looks like type, but it is just an instance for 3.7.

  import typing
  import collections.abc as cabc
  print(issubclass(typing.MutableMapping, cabc.Mapping))  # Python 3.7 raises TypeError

I don't think it's real problem.  But if someone claims it's real issue, we can make typing.MutableMapping more "class-like" by adding __mro__.

diff --git a/Lib/typing.py b/Lib/typing.py
index 7ca080402e..2edaa3f868 100644
--- a/Lib/typing.py
+++ b/Lib/typing.py
@@ -619,6 +619,7 @@ def __init__(self, origin, params, *, inst=True, special=False, name=None):
                               a for a in params)
         self.__parameters__ = _collect_type_vars(params)
         self.__slots__ = None  # This is not documented.
+        self.__mro__ = (origin,) + getattr(origin, '__mro__', (object,))
         if not name:
             self.__module__ = origin.__module__


Again, I don't think it's a real problem.
Maybe, we can add the check, and revert it if someone claims.