bpo-32717: Document PEP 560

Doc/library/types.rst

@@ -59,7 +59,7 @@ Dynamic Type Creation
 
       The default value for the ``namespace`` element of the returned
       tuple has changed.  Now an insertion-order-preserving mapping is
-      used when the metaclass does not have a ``__prepare__`` method,
+      used when the metaclass does not have a ``__prepare__`` method.
 
 .. seealso::
 
@@ -69,6 +69,23 @@ Dynamic Type Creation
    :pep:`3115` - Metaclasses in Python 3000
       Introduced the ``__prepare__`` namespace hook
 
+.. function:: resolve_bases(bases)
+
+   Resolve MRO entries dynamically as specified by :pep:`560`.
+
+   This function looks for items in *bases* that are not instances of
+   :class:`type`, and returns a tuple where each such object that has
+   an ``__mro_entries__`` method is replaced with an unpacked result of
+   calling this method.  If a *bases* item is an instance of :class:`type`,
+   or it doesn't have an ``__mro_entries__`` method, then it is included in
+   the return tuple unchanged.
+
+   .. versionadded:: 3.7
+
+.. seealso::
+
+   :pep:`560` - Core support for typing module and generic types
+
 
 Standard Interpreter Types
 --------------------------

Doc/reference/datamodel.rst

@@ -1857,11 +1857,27 @@ passed through to all metaclass operations described below.
 
 When a class definition is executed, the following steps occur:
 
+* MRO entries are resolved
 * the appropriate metaclass is determined
 * the class namespace is prepared
 * the class body is executed
 * the class object is created
 
+
+Resolving MRO entries
+^^^^^^^^^^^^^^^^^^^^^
+
+If a base that appears in class definition is not an instance of :class:`type`,
+then an ``__mro_entries__`` method is searched on it. If found, it is called
+with the original bases tuple. This method must return a tuple of classes that
+will be used instead of this base. The tuple may be empty, in such case
+the original base is ignored.
+
+.. seealso::
+
+   :pep:`560` - Core support for typing module and generic types
+
+
 Determining the appropriate metaclass
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 .. index::
@@ -2061,6 +2077,27 @@ case the instance is itself a class.
       module) to the language.
 
 
+Emulating generic types
+-----------------------
+
+One can implement the generic class syntax as specified by :pep:`484`
+(for example ``List[int]``) by defining a special method
+
+.. classmethod:: object.__class_getitem__(cls, key)
+
+   Return an object representing the specialization of a generic class
+   by type arguments found in *key*.
+
+This method is looked up on the class object itself, and when defined in
+the class body, this method is implicitly a class method.  Note, this
+mechanism is primarily reserved for use with static type hints, other usage
+is discouraged.
+
+.. seealso::
+
+   :pep:`560` - Core support for typing module and generic types
+
+
 .. _callable-types:
 
 Emulating callable objects

Doc/whatsnew/3.7.rst

@@ -356,6 +356,25 @@ with the correct context in async/await code.
        PEP written and implemented by Yury Selivanov
 
 
+PEP 560: Core support for typing module and generic types
+---------------------------------------------------------
+
+Initially :pep:`484` was designed in such way that it would not introduce *any*
+changes to the core CPython interpreter. Now type hints and the :mod:`typing`
+module are extensively used by the community, so this restriction is removed.
+The PEP introduces two special methods :meth:`__class_getitem__` and
+``__mro_entries__``, these methods are now used by most classes and special
+constructs in :mod:`typing`. As a result, the speed of various operations
+with types increased up to 7 times, the generic types can be used without
+metaclass conflicts, and several long standing bugs in :mod:`typing` module are
+fixed.
+
+.. seealso::
+
+   :pep:`560` -- Core support for typing module and generic types
+      PEP written and implemented by Ivan Levkivskyi
+
+
 New Development Mode: -X dev
 ----------------------------