clarify more details
This commit is contained in:
parent
3d20e37391
commit
1f9366430b
|
@ -232,7 +232,7 @@ PEP::
|
|||
Implementation Details
|
||||
======================
|
||||
|
||||
The different hooks are called in the following order: ``type.__new__`` calls
|
||||
The hooks are called in the following order: ``type.__new__`` calls
|
||||
the ``__set_name__`` hooks on the descriptor after the new class has been
|
||||
initialized. Then it calls ``__init_subclass__`` on the base class, on
|
||||
``super()``, to be precise. This means that subclass initializers already
|
||||
|
@ -245,6 +245,12 @@ even to prevent ``__set_name__`` from being called. Most of the times,
|
|||
however, such a prevention would be accidental, as it often happens that a call
|
||||
to ``super()`` is forgotten.
|
||||
|
||||
As a third option, all the work could have been done in ``type.__init__``.
|
||||
Most metaclasses do their work in ``__new__``, as this is recommended by
|
||||
the documentation. Many metaclasses modify their arguments before they
|
||||
pass them over to ``super().__new__``. For compatibility with those kind
|
||||
of classes, the hooks should be called from ``__new__``.
|
||||
|
||||
Another small change should be done: in the current implementation of
|
||||
CPython, ``type.__init__`` explicitly forbids the use of keyword arguments,
|
||||
while ``type.__new__`` allows for its attributes to be shipped as keyword
|
||||
|
|
Loading…
Reference in New Issue