Maybe the right way to think about Enum is as only for the most trivial use cases. At work we almost never use Enum because it's too limited and we instead reach for our own tri.declarative which scales up to very complex use cases. Adding a lot of features to Enum would make it less of an enum and more like the static tables we are aiming for with tri.declarative. I'm assuming there are performance and memory implications to this.
On 30 Nov 2019, at 09:25, Steve Jorgensen <stevej@stevej.name> wrote:
I brought this up before, but I had a kind of weak understanding of `enum.Enum` at the time, so my expression of the issue and proposal for a solution were pretty awkward.
Basically, with the current implementation of `Enum` and supporting classes, the only way that a member can have access to its own name during or prior to its initialization is if/when its value is auto-generated, so if you want to specify a value rather than having it auto-generated (e.g. to generate a label attribute) then there's no convenient way to do it.
One can work around that by writing the code to make use of the `name` property after installation, but why should we force the developer to write code in an awkward manner when we could simply make the name available to the `__new__ method. It might also be nice to supply the list of all names (in case the value is assigned to multiple names) as well as the primary name.
The idea that comes to mind is to pass a `context` object argument to `__new__` with `name` and `names` attributes. To preserve backward compatibility, there could be have a class attribute named something like `_use_context_` (`False` by default) to enable or disable passing that parameter. Going forward, additional attributes could be added to the context without additional backward compatibility concerns.
Of course, the exact mechanism could be something completely different, but I'd like to see this or some other mechanism that addresses the concern. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2RCMJ2... Code of Conduct: http://python.org/psf/codeofconduct/