Andrew Barnert wrote:
What you’re describing is just enum.Enum, minus half its features, but a sequence instead of a mapping. I’m not sure why you’d ever want this,
Actually, it's a bit different. This is for building a collection of value/label pairs where the values are as likely to be strings as numbers, and its sequence behavior is as a list of value/label pairs (e.g. for use as the choices for a Django field).
but if you did, you could just subclass EnumMeta and add/override the sequence methods. At any rate, almost all of that seems irrelevant to your issue. Making it act like both a singleton with members and like a sequence is already trivial to do today. What you’re looking for is a way to auto-assign attributes on lookup during class definition. Which is an idea that was actually brought up for enums, and specifically rejected in PEP 435, but there’s a proof of concept implementation of it anyway if you want it.
OK. I'm not at all surprised that was rejected. In that case, perhaps the answer to my proposal is — nobody should be doing this kind of thing, so there's no reason to work around the limitations of trying to do this kind of thing. :)
It’s also worth looking at the implementation of the various alternative enum implementations on PyPI (both the ones that pre-existed 3.4, and the ones that build on it).
Yes. I'll take a look. My code and this DSL was probably never going to be used in production anyway because it primarily a learning exercise. Possibly actually using it is a distant second priority. Reading those alternative implementations is, of course, also a good learning exercise. :)