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

[Glenn Linderman]

On 5/20/2013 11:44 PM, Glenn Linderman wrote:
> On 5/14/2013 7:16 AM, Ethan Furman wrote:
>>> Thank you for being persistent.  You are correct, the value should 
>>> be an IntET (at least, with a custom __new__ ;).
>>
>> You know, when you look at something you wrote the night before, and 
>> have no idea what you were trying to say, you know you were tired.  
>> Ignore my parenthetical remark.
>
> Gladly. And we now have several more days to have forgotten what we 
> were doing/talking about...
>
>> Okay, the value is now an IntET, as expected and appropriate. 
>
> Maybe.
>
> I upgraded my ref435.py from yours at 
> https://bitbucket.org/stoneleaf/ref435 (and your test file there 
> references enum.py which is not there).
>
> My demo1.py still doesn't work.  The first 4 lines are fine, but not 
> the last two.  I still cannot do a lookup (via __call__ syntax) by 
> either int or IntET value.
>
> You have my old misnamed NEI class in your test file now, and the 
> tests you use with it work... but you don't have a lookup test. My 
> demo1 does, and that fails.
>
> After instrumenting Enum.__new__ it seems that the member.value is 
> still the constructor parameters...
>
> Maybe I picked up the wrong version of your code?
>
> Oh and demo1.py has leftover __new__ and __init__ definitions for NIE, 
> modeled after your earlier suggestions. Leaving them in causes 
> everything to be named 'temp'. Taking them out makes things not work 
> differently.

Oh, it was an hg misunderstanding (hg newbie here)... I wasn't getting 
the latest code.  Things are working much better now.

I notice, however, with my latest code at 
https://v_python@bitbucket.org/v_python/ref435a that demo1, which has an 
explicit duplicate name, and no __new__  or __init__ code, has a .value 
which is actually a IntET (as shown by the last print of the repr of the 
value).  However, demo2, which attempts to "marry" the classes and avoid 
the duplicate name specifications, has a .value which is an "unnamed" 
IntET, whereas one would expect it to be named.

Noticing the changes you made, I think it is a result of line 177 in 
ref435.py where you actually instantiate a 2nd copy of IntET—using the 
same parameters, but a separate instantiation from the 
"married-with-Enum" copy—to use as the value.  I guess there is no way 
to "extract" the IntET from the "married-with-Enum" copy, to use as the 
value?  So then, this is good, but not quite good enough: the 2nd copy 
of the IntET should have the same name as the "married-with-Enum" copy.

Now in demo4.py I figured out how I could fix that, since the second 
copy is (currently) made before the __init__ call for the 
"married-with-Enum" copy, and stored in an accessible place.

On the other hand, it is a bit of a surprise to have to do that, and it 
would also be a bit of a surprise for classes that have class state that 
affects the instantiation of instances... That might just mean that some 
classes can't be mixed with Enum, but I suppose known restrictions 
and/or side effects should be documented.

As an example of this, I tried to resurrect your AutoNumber from your 
message of 6 May 2013 19:29 -0700 in the "PEP 435: initial values must 
be specified? Yes" thread, but couldn't, apparently due to changes in 
the implementation of ref435, but after fixing those problems, I still 
got an error where it demanded a parameter to new, even though one 
shouldn't be needed in that case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130521/4fc1c065/attachment.html>