[Python-Dev] PEP 435 - ref impl disc 2

Ethan Furman ethan at stoneleaf.us
Tue May 14 08:11:28 CEST 2013

On 05/13/2013 10:01 PM, Glenn Linderman wrote:
> On 5/13/2013 7:36 PM, Ethan Furman wrote:
>> On 05/10/2013 10:15 PM, Glenn Linderman wrote:
>>> So it is quite possible to marry the two, as Ethan helped me figure out using an earlier NamedInt class:
>>> class NIE( IntET, Enum ):
>>>      x = ('NIE.x', 1)
>>>      y = ('NIE.y', 2)
>>>      z = ('NIE.z', 4)
>>> and then expressions involving members of NIE (and even associated integers) will be tracked... see demo1.py.
>>> But the last few lines of demo1 demonstrate that NIE doesn't like, somehow, remember that its values, deep down under
>>> the covers, are really int.  And doesn't even like them when they are wrapped into IntET objects.  This may or may not
>>> be a bug in the current Enum implementation.
>> [demo1.py excerpt]
>>     print( repr( NIE1( 1 ) + NIE1(2)))
>>     print( repr( NIE1( IntET('NIE1.x', 1 )) + NIE1(2)))
>>> So the questions are:
>>> 1) Is there a bug in ref435 Enum that makes demo1 report errors instead of those lines working?
>> Nope.
> Well, if it isn't a bug, it will be interesting to read the documentation that explains the behavior, when the
> documentation is written:
> The "obvious" documentation would be that Enum names values of any type, particularly the first type in the
> multiple-inheritance list. The values assigned to the enumeration members are used as parameters to the constructor of
> that first type, but the value of the enumeration member itself is an item of the type, created by the constructor.
> The __call__ syntax  [ EnumDerivation( value ) ] looks up enumeration members by value.
> The obvious documentation would stop there.

> The one piece of "marriage" that is interesting is to avoid specifying the name twice, and it seems your code
> I'd expect  NIE1.x.value  to be  IntET('x', 1)  but I'll have to look more carefully at what you've done, when I have
> some time next week. You may have made some "simplifying assumptions", and things _should_ be as simple as possible, but
> no simpler... especially not if it leads to unexpected results.

> This will take more thought than I have time for tonight, also. Right now, I think I want the value for NIE.x to be
> IntET('NIE.x', 1 ).  And your code isn't achieving that at present, but maybe I just need to tweak __new__ and then
> can... and maybe it cures the discrepancy in expectations mentioned earlier too...

Thank you for being persistent.  You are correct, the value should be an IntET (at least, with a custom __new__ ;).

I'll look into it.


More information about the Python-Dev mailing list