Specialize access to Enum attributes

[markshannon]

Currently we don't specialize loading of enum attributes.

class Color(Enum):
     RED = "Red"

Color.RED   # This load is not specialized

We can take advantage of the fact that type(Color.RED) == Color when specializing.
Since we check the version number of Color in LOAD_ATTR_CLASS, we are implicitly checking the version of type(Color.RED).
If Color.RED is not a descriptor when specialized, it will not be a descriptor when executed.
Therefore, we can specialize it in the same way as immutable, non-descriptor class attributes using LOAD_ATTR_CLASS.

@Fidget-Spinner
@brandtbucher

Linked PRs

• gh-95004: specialize access to enums and fix scaling on free-threading #148184

[Fidget-Spinner]

Are you working on this?

[markshannon]

Are you working on this?

No. If you want to do this, just assign yourself.
It might be worth waiting for 3.11 to calm down a bit first.

[brandtbucher]

I imagine that this will piggyback off of #93988, since EnumType defines __getattr__?

[ethanfurman]

__getattr__ is no longer necessary, and will be removed in 3.12 (since I forgot to do it in 3.11).

[ethanfurman]

If Color.RED is not a descriptor when specialized, it will not be a descriptor when executed. Therefore, we can specialize it in the same way as immutable, non-descriptor class attributes using LOAD_ATTR_CLASS.

Even if Color.__dict__['RED'] is a descriptor, its result will still always be the member Color.RED when called on the class. Is that optimizable?

In case it matters, the exact descriptor would be enum.property -- the big difference between it and the standard property is the behavior when called on the class -- either the matching enum member, or an AttributeError.

[brandtbucher]

Even if Color.__dict__['RED'] is a descriptor, its result will still always be the member Color.RED when called on the class. Is that optimizable?

Interesting. Looking at it now, I'm not sure why LOAD_ATTR_CLASS currently only handles methods and non-descriptors. As you note, it should be able to handle anything (at least anything without a descriptor in the metaclass, which we already guard against), including descriptors in the class __dict__.

@Fidget-Spinner?

[Fidget-Spinner]

@brandtbucher it's probably an oversight in how I implemented it. I was being conservative at the time (also I admit just using the direct results from the analyze_descriptor function for simplicity).

[Fidget-Spinner]

Some complications with specialising enums:

• Inheriting from enums uses metaclasses. Which we (just) disabled.
• The enum metaclass is a mutable class. Which we don't specialize (it may be dangerous to).
• The enum property is a descriptor.

We probably need a specialisation for metaclasses, like what Brandt suggested in his other PR.

[markshannon]

Inheriting from enums uses metaclasses. Which we (just) disabled.

All classes have a metaclass. The issue is whether the metaclass is mutable, has overrides, or shadows class attributes.
This is much the same as for normal instances and their classes, which is why we have analyze_descriptor

The enum metaclass is a mutable class.

This is the only problem here, AFAICT. The easy fix is to make EnumType immutable. It doesn't need to be mutable.
A more general, and much more complex fix is to update the version number of all classes that are instances of a metaclass, when that metaclass changes.

The enum property is a descriptor.

Properties are descriptors. Which property are you talking about?

[Fidget-Spinner]

Properties are descriptors. Which property are you talking about?

This part is wrong. I initially assumed enum members defined __get__ and __set__. I don't think they do.

[brandtbucher]

This part is wrong. I initially assumed enum members defined __get__ and __set__. I don't think they do.

No, I think it's just name and value that do that. Still something to consider, though.