Add an ordered `StrEnum` variant

[placTc]

Feature or enhancement

Proposal:

I've had a reason to use modified StrEnums ordered in the order of declaration of enum values to easily describe objects like string-named permissions. I think adding it as a base option for enums or as a decorator for StrEnums in the stdlib would be great

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

[ethanfurman]

Enum members are already ordered by declaration:

>>> class Permission(StrEnum):
...     READ = 'read'
...     WRITE = 'write'
...     EXECUTE = 'execute'
...     
>>> list(Permission)
[<Permission.READ: 'read'>, <Permission.WRITE: 'write'>, <Permission.EXECUTE: 'execute'>]

If you meant something else, please provide an example.

[xdefago]

I came into this discussion when searching for the same problem. I believe that the issue is as follows. Want (declaration order):

assert Permission.READ < Permission.WRITE
assert Permission.WRITE < Permission.EXECUTE

Currently, with StrEnum, an implicit ordering is defined on the strings, as follows (lexical order):

assert Permission.EXECUTE < Permission.READ
assert Permission.READ < Permission.WRITE

The proposal is to somehow provide an option to explicitly require an implicit order defined on the declaration order rather than the associated string value.
This is a minor feature but it would make the code clearer in some circumstances (e.g., when dealing with access rights or named priorities).

[picnixz]

That's an interesting proposal. It does make sense but it's at the same time, extremely fragile. I would also use an integral enum here instead of a string enum so I don't know whether we should support this even for named priorities (using an IntEnum + overriding __str__ or provide a custom property for the named priority is IMO better)

[placTc]

@ethanfurman While the enum members are already ordered when converted to a list, and I did make use of that fact in my code for the time being, I am indeed referring to what @xdefago has mentioned.

There could be an ordered StrEnum variant that bases its implementation of comparison methods on the members' index instead of their lexical properties.

This indeed helps slim down code that deals, for example, with external systems' access rights. This is a common situation when both the string value of the Enum and its order among the members matters.

Overriding __str__ wouldn't be ideal for this IMO because it would mean declaring the Enum twice in a way, once for the numerical values and once for the string representations.