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 ste...@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-le...@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. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/KVZ7OKKHY3LV54C4OTBBVXWAFPIM4P2W/ Code of Conduct: http://python.org/psf/codeofconduct/
