[Python-Dev] PEP 435 - ref impl disc 2
v+python at g.nevcal.com
Tue May 21 11:16:23 CEST 2013
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.
> 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
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://email@example.com/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...
More information about the Python-Dev