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_pyt...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
