[Python-Dev] PEP: Ordered Class Definition Namespace (original) (raw)

Ethan Furman ethan at stoneleaf.us
Tue Jun 7 17:34:58 EDT 2016

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:

* _definitionorder_ is a tuple * _definitionorder_ 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 definitionorder 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 definitionorder to strictly represent what happened in the class body during definition, and not anything afterward. Certainly definitionorder 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 definitionorder 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 definitionorder, 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 definitionorder 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 definitionorder more complicated and less useful. As the PEP stands, folks can be confident in what definitionorder represents. What would you consider to be the benefit of a mutable (or replaceable) definitionorder that outweighs the benefit of a simpler definition of what's in it.

I think the question is which is more useful?

or

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

More information about the Python-Dev mailing list