PEP 520: Resolve the open questions.

pep-0520.txt

@@ -105,7 +105,6 @@ Part 1:
 
 * all classes have a ``__definition_order__`` attribute
 * ``__definition_order__`` is a ``tuple`` of identifiers (or ``None``)
-* ``__definition_order__`` is a read-only attribute
 * ``__definition_order__`` is always set:
 
   1. during execution of the class body, the insertion order of names
@@ -157,26 +156,35 @@ is already complete by the time ``__definition_order__`` is set, the
 content and order of the value won't be changing.  Thus we use a type
 that communicates that state of immutability.
 
-Why a read-only attribute?
---------------------------
+Why not a read-only attribute?
+------------------------------
 
-As with the use of tuple, making ``__definition_order__`` a read-only
-attribute communicates the fact that the information it represents is
-complete.  Since it represents the state of a particular one-time event
-(execution of the class definition body), allowing the value to be
-replaced would reduce confidence that the attribute corresponds to the
-original class body.
+There are some valid arguments for making ``__definition_order__``
+a read-only attribute (like ``cls.__dict__`` is).  Most notably, a
+read-only attribute conveys the nature of the attribute as "complete",
+which is exactly correct for ``__definition_order__``.  Since it
+represents the state of a particular one-time event (execution of
+the class definition body), allowing the value to be replaced would
+reduce confidence that the attribute corresponds to the original class
+body.  Furthermore, often an immuntable-by-default approach helps to
+make data easier to reason about.
 
-If a use case for a writable (or mutable) ``__definition_order__``
-arises, the restriction may be loosened later.  Presently this seems
-unlikely and furthermore it is usually best to go immutable-by-default.
+However, in this case there still isn't a *strong* reason to counter
+the well-worn precedent found in Python.  Per Guido::
+
+    I don't see why it needs to be a read-only attribute. There are
+    very few of those -- in general we let users play around with
+    things unless we have a hard reason to restrict assignment (e.g.
+    the interpreter's internal state could be compromised). I don't
+    see such a hard reason here.
+
+Also, note that a writeable ``__definition_order__`` allows dynamically
+created classes (e.g. by Cython) to still have ``__definition_order__``
+properly set.  That could certainly be handled through specific class-
+creation tools, such as ``type()`` or the C-API, without the need to
+lose the semantics of a read-only attribute.  However, with a writeable
+attribute it's a moot point.
 
-Note that if ``__definition_order__`` were not read-only then it would
-allow dynamically created classes (e.g. by Cython) to still have
-``__definition_order__`` properly set.  However, if this is important
-then it could be handled through specific class-creation tools, such as
-``type()`` or the C-API without the need to lose the semantics of a
-read-only attribute.
 
 Why not "__attribute_order__"?
 ------------------------------
@@ -259,6 +267,14 @@ to consider ``__definition_order__`` a class-only attribute, hidden
 during lookup on objects, setting precedent in that regard is
 beyond the goals of this PEP.
 
+What about __slots__?
+---------------------
+
+``__slots__`` will be added to ``__definition_order__`` like any
+other name in the class definition body.  The actual slot names
+will not be added to ``__definition_order__`` since they aren't
+set as names in the definition namespace.
+
 Why is __definition_order__ even necessary?
 -------------------------------------------
 
@@ -277,7 +293,9 @@ Arguably, most C-defined Python types (e.g. built-in, extension modules)
 have a roughly equivalent concept of a definition order. So conceivably
 ``__definition_order__`` could be set for such types automatically. This
 PEP does not introduce any such support. However, it does not prohibit
-it either.
+it either.  However, since ``__definition_order__`` can be set at any
+time through normal attribute assignment, it does not need any special
+treatment in the C-API.
 
 The specific cases:
 
@@ -304,6 +322,11 @@ In addition to the class syntax, the following expose the new behavior:
 * types.prepare_class
 * types.new_class
 
+Also, the 3-argument form of ``builtins.type()`` will allow inclusion
+of ``__definition_order__`` in the namespace that gets passed in.  It
+will be subject to the same constraints as when ``__definition_order__``
+is explicitly defined in the class body.
+
 
 Other Python Implementations
 ============================
@@ -313,26 +336,6 @@ be minimal.  All conforming implementations are expected to set
 ``__definition_order__`` as described in this PEP.
 
 
-Open Questions
-==============
-
-* What about `__slots__`?
-
-* Allow setting ``__definition_order__`` in ``type()``?
-
-* C-API for setting ``__definition_order__``?
-
-* Drop the "read-only attribute" requirement?
-
-Per Guido:
-
-    I don't see why it needs to be a read-only attribute. There are
-    very few of those -- in general we let users play around with
-    things unless we have a hard reason to restrict assignment (e.g.
-    the interpreter's internal state could be compromised). I don't
-    see such a hard reason here.
-
-
 Implementation
 ==============