Fwd: Allow Enum members to refer to each other during execution of body
Sorry for the duplicate, seems like sending just to the googlegroups address doesn't cc to the python.org address. My previous email below. Antony 2013/7/12 Antony Lee <antony.lee@berkeley.edu>
Is there any specific reason why you do not wish to change the behavior of Enum to this one (which does seem more logical to me)? The patch is fairly simple in its logic (compared to the rest of the implementation, at least...), and I could even change it to remove the requirement of defining __new__ before the members as long as there are no references to other members (because as long as there are no references to other members, I obviously don't need to actually create the members), thus making it fully compatible with the current version. Antony
2013/7/11 Ethan Furman <ethan@stoneleaf.us>
On 07/11/2013 02:07 PM, Antony Lee wrote:
On Wednesday, July 10, 2013 6:52:24 PM UTC-7, stoneleaf wrote:
On 07/10/2013 03:47 PM, Antony Lee wrote:
Forward references are now implemented (https://github.com/anntzer/** enum <https://github.com/anntzer/enum> <https://github.com/anntzer/** enum <https://github.com/anntzer/enum>>).
Do they work with a custom __new__ ? __init__ ?
In the current version, they work with a custom __init__ (though of course, as long as the actual arguments that need to be passed to __init__ are provided, the pre-declared members are just "empty"). They do not work with a custom __new__ (not sure how I could make this work, given that at declaration time an "empty" member needs to be created but we don't know what arguments we need to pass to __new__...). As a side effect, however, the whole patch adds a new requirement: custom __new__s must be defined before the members themselves; otherwise they won't be called, for the same reason as above: if I don't know what __new__ is, I can't call it...
Hmm. Well, at this point I can offer kudos for getting it this far, but that's about it. The use-case this addresses seems fairly rare, and is definitely not a typical enumeration, and can be solved fairly easily with some extra post-processing code on a per-enumeration basis.
-- ~Ethan~ ______________________________**_________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/**mailman/listinfo/python-ideas<http://mail.python.org/mailman/listinfo/python-ideas>
--
--- You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group. To unsubscribe from this topic, visit https://groups.google.com/d/** topic/python-ideas/PC_**Ej19qj5w/unsubscribe<https://groups.google.com/d/topic/python-ideas/PC_Ej19qj5w/unsubscribe> . To unsubscribe from this group and all its topics, send an email to python-ideas+unsubscribe@**googlegroups.com<python-ideas%2Bunsubscribe@googlegroups.com> . For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> .
On 07/14/2013 02:36 PM, Antony Lee wrote:
Is there any specific reason why you do not wish to change the behavior of Enum to this one (which does seem more logical to me)? The patch is fairly simple in its logic (compared to the rest of the implementation, at least...), and I could even change it to remove the requirement of defining __new__ before the members as long as there are no references to other members (because as long as there are no references to other members, I obviously don't need to actually create the members), thus making it fully compatible with the current version.
My apologies for the delay in replying. Getting Enum into the stdlib was a very careful balancing act: - Make it powerful enough to meet most needs as-is - Make it extensible enough that custom enumerations could be easily implemented - Make it simple enough to not create a large cognitive burden How this relates to your patch: 1) With your patch, referencing another enum member either returns the member itself (pure Enum), or the value of the Enum (mixed Enum) -- which means two different behaviors from the same syntax. 2) The patch fails with the pure Enum with auto-numbering test case. It fails because __new__ is looking at the __member__ data structure which is empty for the duration of __prepare__. While work arounds are possible, they would not be simpler, or even as simple. Summary: The resulting behavior is inconsistent, and the complexity added to the code, but mostly to the mind, is much greater than the minor benefit. -- ~Ethna
participants (2)
-
Antony Lee -
Ethan Furman