From c6c695732adf92f3bfa4ce663ae31113c433752e Mon Sep 17 00:00:00 2001 From: ericsnowcurrently Date: Tue, 28 Jun 2016 14:40:13 -0600 Subject: [PATCH] PEP 520: Resolve the open questions. --- pep-0520.txt | 81 +++++++++++++++++++++++++++------------------------- 1 file changed, 42 insertions(+), 39 deletions(-) diff --git a/pep-0520.txt b/pep-0520.txt index b86784d9a..7fe42ffc0 100644 --- a/pep-0520.txt +++ b/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 ==============