On 06/07/2016 02:20 PM, Eric Snow wrote:
On Tue, Jun 7, 2016 at 12:30 PM, Nick Coghlan wrote:
On 7 June 2016 at 10:51, Eric Snow wrote:
* ``__definition_order__`` is a tuple
* ``__definition_order__`` is a read-only attribute
Thinking about the class decorator use case, I think this may need to
be reconsidered, as class decorators may:
1. Remove class attributes
2. Add class attributes
This will then lead to __definition_order__ getting out of sync with
the current state of the class namespace.
I'm not clear on your point. Decorators are applied after the class
has been created. Hence they have no impact on the class's definition
order. I'd expect __definition_order__ to strictly represent what
happened in the class body during definition, and not anything
afterward.
Certainly __definition_order__ might not align with __dict__ (or
dir()); we don't have any way to guarantee that it would, do we? If
anything, the ability to diff __definition_order__ and __dict__ is a
positive, since it allows you to see changes on the class since it was
defined.
One option for dealing with that would be to make type.__setattr__ and
type.__delattr__ aware of __definition_order__, and have them replace
the tuple with a new one as needed. If we did that, then the main
question would be whether updating an existing attribute changed the
definition order, and I'd be inclined to say "No" (to minimise the
side effects of monkey-patching).
The main alternative would be to make __definition_order__ writable,
so the default behaviour would be for it to reflect the original class
body, but decorators would be free to update it to reflect their
changes, as well as to make other modifications (e.g. stripping out
all callables from the list).
I think both of those make __definition_order__ more complicated and
less useful. As the PEP stands, folks can be confident in what
__definition_order__ represents. What would you consider to be the
benefit of a mutable (or replaceable) __definition_order__ that
outweighs the benefit of a simpler definition of what's in it.
I think the question is which is more useful?
- a definition order that lists items that are not in the class, as
well as not having items that are in the class (set by the decorator)
or
- a definition order that is representative of the class state after
all decorators have been applied
One argument for the latter is that, even though the class has been
technically "defined" (class body executed, type.__new__ called, etc.),
applying decorators feels like continued class definition.
One argument for the former is simplified implementation, and is
definition order really important after the class body has been
executed? (okay, two arguments ;)
Perhaps the best thing is just to make it writeable -- after all, if
__class__, __name__, etc., can all be changed, why should
__definition_order__ be special?
--
~Ethan~
_______________________________________________
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
