Anders Hovmöller wrote:
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/
I get what you're saying, and thanks for letting me know about `tri.declarative`. I'll read up on that. I feel like what I'm asking for is a small change to eliminate a frustrating, unnecessary restriction in `Enum` though, and not something to make it handle a higher order of complex situation.