This version looks fine to me. On 24 June 2016 at 14:52, Eric Snow <ericsnowcurren...@gmail.com> wrote: > Background > ========== > > When a class is defined using a ``class`` statement, the class body > is executed within a namespace. Currently that namespace defaults to > ``dict``. If the metaclass defines ``__prepare__()`` then the result > of calling it is used for the class definition namespace. > > After the execution completes, the definition namespace namespace is > copied into new ``dict``. Then the original definition namespace is > discarded. The new copy is stored away as the class's namespace and > is exposed as ``__dict__`` through a read-only proxy. > > The class attribute definition order is represented by the insertion > order of names in the *definition* namespace. Thus, we can have > access to the definition order by switching the definition namespace > to an ordered mapping, such as ``collections.OrderedDict``. This is > feasible using a metaclass and ``__prepare__``, as described above. > In fact, exactly this is by far the most common use case for using > ``__prepare__`` (see PEP 487).
The definition order question has been dropped from PEP 487, so this cross-reference doesn't really make sense any more :) > Part 2: > > * the default class *definition* namespace is now ``OrderdDict`` > > The following code demonstrates roughly equivalent semantics for the > default behavior:: > > class Meta(type): > @classmethod > def __prepare__(cls, *args, **kwargs): > return OrderedDict() > > class Spam(metaclass=Meta): > ham = None > eggs = 5 > __definition_order__ = tuple(locals()) I'd characterise this section at the language definition level as the default class definition namespace now being *permitted* to be an OrderedDict. For implementations where dict is ordered by default, there's no requirement to switch specifically to collections.OrderedDict. > Why 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. > > 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. > > Note that the ability to set ``__definition_order__`` manually allows > a dynamically created class (e.g. Cython, ``type()``) to still have > ``__definition_order__`` properly set. This paragraph is a little confusing, since "set ``__definition_order__`` manually" is ambiguous. "supply an explicit ``__definition_order__`` via the class namespace" might be clearer. > Why not ignore "dunder" names? > ------------------------------ > > Names starting and ending with "__" are reserved for use by the > interpreter. In practice they should not be relevant to the users of > ``__definition_order__``. Instead, for nearly everyone they would only > be clutter, causing the same extra work for everyone. > > However, dropping dunder names by default may inadvertantly cause > problems for classes that use dunder names unconventionally. In this > case it's better to play it safe and preserve *all* the names from > the class definition. > > Note that a couple of dunder names (``__name__`` and ``__qualname__``) > are injected by default by the compiler. So they will be included even > though they are not strictly part of the class definition body. I realised there's another important reason for doing it this way by default: it's *really easy* to write a "skip_dunder_names" filter that leaves out dunder names from an arbitrary interable of strings. It's flatout *impossible* to restore the dunder attribute order if the class definition process throws it away. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
