[Python-ideas] Fwd: Allow Enum members to refer to each other during execution of body

[Antony Lee]

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 at 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 at 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 at 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 at googlegroups.com>
>> .
>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130714/b908adcf/attachment-0001.html>