On Tue, Jun 7, 2016 at 2:34 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 06/07/2016 02:20 PM, Eric Snow wrote:
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
"definition" refers explicitly to the execution of the class body in a class statement. So what you've described is a bit confusing to me. If we're talking about some other semantics then the name "__definition_order__" is misleading. Also, consider that __definition_order__ is, IMHO, most useful when interpreted as the actual order of attributes in the class definition body. The point is that code outside the class body can leverage the order of assigned names within that block. So, relative to the class definition, I'm not clear on valid use cases that divorce themselves from the class definition, such that either of your scenarios is relevant. Semantics that relate more to the class namespace (__dict__) are a separate matter from this PEP. I'd welcome a broader solution that still met the needs at which __definition_order__ is aiming. For example, consider if the class's __dict__ (or rather the proxied value) were OrderedDict. In fact, Guido was originally (in 2013) amenable to that idea. However, I tried it and making it work was a challenge due to use of the concrete dict C-API. I'd be glad if it was worked out. In the meantime, this PEP is more focused on a practical representation of the ordering information inside just the class definition body.
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.
Perhaps. That doesn't align with my intuition on decorators, but I'll readily concede that my views aren't always particularly representative of everyone else. :) That said, there are many different uses for decorators and modifying the class namespace (__dict__) isn't the only one (and in my experience not necessarily the most common).
One argument for the former is simplified implementation,
I'm not sure what you're implying about the implementation. Do you mean that it's easier than just letting __definition_order__ be writable (or mutable)? It's actually slightly more work to make it a read-only attr. Perhaps you mean that the semantics in the PEP are easier to implement than something that tracks changes to the class namespace (__dict__) after definition is over? Probably, though I don't see anything like that happening (other than if OrderedDict were used for __dict__).
and is definition order really important after the class body has been executed? (okay, two arguments ;)
Given that the focus is on class definition, I'd argue no. :)
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?
Not all attrs are writable and it's a case-by-case situation: some of the ones that are writable started out read-only and changed once there was a valid reason. If anything, it's arguably safer in general to take an immutable-by-default approach. -eric