]> granicus.if.org Git - python/commitdiff
bpo-32717: Document PEP 560 (GH-6726)
authorIvan Levkivskyi <levkivskyi@gmail.com>
Tue, 8 May 2018 18:38:41 +0000 (19:38 +0100)
committerGitHub <noreply@github.com>
Tue, 8 May 2018 18:38:41 +0000 (19:38 +0100)
Doc/library/types.rst
Doc/reference/datamodel.rst
Doc/whatsnew/3.7.rst

index 67cd4d702ad4a61b681049b5b2b9c19d58944ff6..e17070022cd2ede364653288c7b9561f4204100d 100644 (file)
@@ -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
 --------------------------
index 1e93ef4594a93441acb06bac8245703183a78cc2..b4a0dbf95ec0742f518b27b0224c251f791f827d 100644 (file)
@@ -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
index 408fed4572fab3c35a6fbbe022b2b63fea8b43ba..cc762736a0c7cb3772330916898a0e3405202b77 100644 (file)
@@ -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
 ----------------------------