> On 30 Nov 2019, at 23:30, Steve Jorgensen <[email protected]> wrote: > > 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 [email protected] 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 -- [email protected] >>> To unsubscribe send an email to [email protected] >>> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >>> Message archived at >>> https://mail.python.org/archives/list/[email protected]/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.
Oops! I meant tri.token actually! Which is based on tri.declarative. _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/KOK3EZSOATNFKAAFGGHZ7AFO2ACRX436/ Code of Conduct: http://python.org/psf/codeofconduct/
