[Python-Dev] PEP 435 - ref impl disc 2 (original) (raw)
Glenn Linderman v+python at g.nevcal.com
Sat May 11 09:11:49 CEST 2013
- Previous message: [Python-Dev] PEP 435 - ref impl disc 2
- Next message: [Python-Dev] PEP 435 - ref impl disc 2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 5/10/2013 11:02 PM, Ethan Furman wrote:
On 05/10/2013 10:15 PM, Glenn Linderman wrote:
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. You're right, sort of. ;) If you do print( repr( NIE1.x.value )) you'll see ('NIE1.x', 1) In other words, the value of NEI.x is
('NEI1.x', 1)and that is what you would have to pass back into NEI to get the enum member.
Ah! But the value of NIE.x should be IntET('NIE.x', 1), no? So Enum is presently saving the constructor parameters as the value, rather than the constructed object? So for Enums of builtin types, there is little difference, but for complex types (as opposed to complex numbers), there is a difference, and I guess I ran into the consequences of that difference.
As an aside, I suspect you are doing this the hard way. Perhaps writing your own new in NIE will have better results
NIE.new wouldn't have the name available, unless it is passed in. So it seems to me that Enum (or Enum+) has to pass in the parameter... in which case NIE.new can be pretty ordinary.
Other implementation strategies that occurred to me... maybe I'll try them all, if I have time... but time looks to get scarcer soon...
I'm playing with adding another keyword parameter to Enum, but it is presently giving me an error about unknown keyword parameter passed to prepare even though I added **kwds to the list of its parameters. I'll learn something by doing this.
Implement a subclass of Enum that has a bunch of operator tracking methods like IntET. However, the results of arithmetic operations couldn't add a new enumeration member (legally), so some other type would still have to exist... and it would also have to have those operation tracking methods.
Implement a subclass of EnumMeta that installs all the operator tracking methods. Same legal issue.
Do one of the above, but allow new calculated members to exist, although perhaps not in the initial, iterable set. Might have to call it something besides Enum to obey the proclamations :) FlagBits, maybe.
But it could use much the same technology as Enum.
(I'd try, but I gotta get some sleep! ;) .
Thanks for the response... it cleared up the demo1 mystery, anyway.
Oh, newest code posted.
That'll give me some practice pulling from your repository into mine :) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130511/a37cd90f/attachment.html>
- Previous message: [Python-Dev] PEP 435 - ref impl disc 2
- Next message: [Python-Dev] PEP 435 - ref impl disc 2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]