Steve Jorgensen 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.
I accidentally omitted some text, leaving that a little unclear. "…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." should read "…so if you want to specify a value rather than having it auto-generated _and_ make use of the name (e.g. to generate a label attribute) then there's no convenient way to do it."