[Python-checkins] peps: Add Daniel as PEP 422 co-author, misc fixes

[nick.coghlan]

http://hg.python.org/peps/rev/8103042eaa56
changeset:   4730:8103042eaa56
user:        Nick Coghlan <ncoghlan at gmail.com>
date:        Sun Feb 10 22:13:58 2013 +1000
summary:
  Add Daniel as PEP 422 co-author, misc fixes

files:
  pep-0422.txt |  37 ++++++++++++++++++++++++++-----------
  1 files changed, 26 insertions(+), 11 deletions(-)


diff --git a/pep-0422.txt b/pep-0422.txt
--- a/pep-0422.txt
+++ b/pep-0422.txt
@@ -2,7 +2,8 @@
 Title: Simple class initialisation hook
 Version: $Revision$
 Last-Modified: $Date$
-Author: Nick Coghlan <ncoghlan at gmail.com>
+Author: Nick Coghlan <ncoghlan at gmail.com>,
+        Daniel Urban <urban.dani+py at gmail.com>
 Status: Draft
 Type: Standards Track
 Content-Type: text/x-rst
@@ -19,7 +20,7 @@
 by setting the ``__metaclass__`` attribute in the class body. While doing
 this implicitly from called code required the use of an implementation detail
 (specifically, ``sys._getframes()``), it could also be done explicitly in a
-fully supported fashion (for example, by passing ``locals()`` to an
+fully supported fashion (for example, by passing ``locals()`` to a
 function that calculated a suitable ``__metaclass__`` value)
 
 There is currently no corresponding mechanism in Python 3 that allows the
@@ -44,7 +45,7 @@
 While in many cases these two meanings end up referring to one and the same
 object, there are two situations where that is not the case:
 
-* If the metaclass hint refers to a subclass of ``type``, then it is
+* If the metaclass hint refers to an instance of ``type``, then it is
   considered as a candidate metaclass along with the metaclasses of all of
   the parents of the class being defined. If a more appropriate metaclass is
   found amongst the candidates, then it will be used instead of the one
@@ -114,7 +115,7 @@
            # This is invoked after the class is created, but before any
            # explicit decorators are called
            # The usual super() mechanisms are used to correctly support
-           # multiple inheritance. The decorator style invocation helps
+           # multiple inheritance. The class decorator style signature helps
            # ensure that invoking the parent class is as simple as possible.
 
 If present on the created object, this new hook will be called by the class
@@ -125,10 +126,17 @@
 If a metaclass wishes to block class initialisation for some reason, it
 must arrange for ``cls.__init_class__`` to trigger ``AttributeError``.
 
+Note, that when ``__init_class__`` is called, the name of the class is not
+bound to the new class object yet. As a consequence, the two argument form
+of ``super()`` cannot be used to call methods (e.g., ``super(Example, cls)``
+wouldn't work in the example above). However, the zero argument form of
+``super()`` works as expected, since the ``__class__`` reference is already
+initialised.
+
 This general proposal is not a new idea (it was first suggested for
 inclusion in the language definition `more than 10 years ago`_, and a
 similar mechanism has long been supported by `Zope's ExtensionClass`_),
-but I believe the situation has changed sufficiently in recent years that
+but the situation has changed sufficiently in recent years that
 the idea is worth reconsidering.
 
 
@@ -156,7 +164,7 @@
 class object) clearly distinct in your mind. Even when you know the rules,
 it's still easy to make a mistake if you're not being extremely careful.
 An earlier version of this PEP actually included such a mistake: it
-stated "instance of type" for a constraint that is actually "subclass of
+stated "subclass of type" for a constraint that is actually "instance of
 type".
 
 Understanding the proposed class initialisation hook only requires
@@ -278,17 +286,24 @@
 Using the current version of the PEP, the scheme originally proposed could
 be implemented as::
 
-   class DynamicDecorators:
+   class DynamicDecorators(Base):
        @classmethod
        def __init_class__(cls):
-           super(DynamicDecorators, cls).__init_class__()
+           # Process any classes later in the MRO
+           try:
+               mro_chain = super().__init_class__
+           except AttributeError:
+               pass
+           else:
+               mro_chain()
+           # Process any __decorators__ attributes in the MRO
            for entry in reversed(cls.mro()):
                decorators = entry.__dict__.get("__decorators__", ())
                for deco in reversed(decorators):
                    cls = deco(cls)
 
-Any subclasses of this type would automatically have the contents of any
-``__decorators__`` attributes processed and invoked.
+Any subclasses of ``DynamicDecorators`` would then automatically have the
+contents of any ``__decorators__`` attributes processed and invoked.
 
 The mechanism in the current PEP is considered superior, as many issues
 to do with ordering and the same decorator being invoked multiple times
@@ -328,7 +343,7 @@
 Reference Implementation
 ========================
 
-Daniel Urban has posted a reference implementation to the `issue tracker`_.
+The reference implementation has been posted to the `issue tracker`_.
 
 
 References

-- 
Repository URL: http://hg.python.org/peps