[Python-Dev] PEP 435 - ref impl disc 2 (original) (raw)

Glenn Linderman 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. 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>

More information about the Python-Dev mailing list