This just doesn't make sense to me:
--> class Stuff(Enum): ... blue = 1 ... china = 'really big country' ... random = (8273.199, 517)
--> Stuff.blue.name == 'blue' --> Stuff.blue.value == 1
--> Stuff.china.name == 'china' --> Stuff.china.value == ???
--> Stuff.random.name == 'random' --> Stuff.china.value == ???
In order to make this work at all, we have to support auto-numbering, and I didn't think we were going to do that in the class syntax?
-- ~Ethan~
P.S. Apologies for all the questions, I'm just hoping to get the last details hammered out so we can stop discussing Enums. ;)
On 04/29/2013 03:50 PM, Ethan Furman wrote:
This just doesn't make sense to me:
--> class Stuff(Enum): ... blue = 1 ... china = 'really big country' ... random = (8273.199, 517)
--> Stuff.blue.name == 'blue' --> Stuff.blue.value == 1
--> Stuff.china.name == 'china' --> Stuff.china.value == ???
--> Stuff.random.name == 'random' --> Stuff.china.value == ???
In order to make this work at all, we have to support auto-numbering, and I didn't think we were going to do that in the class syntax?
I suppose the other option is to have `.value` be whatever was assigned (1, 'really big country', and (8273.199, 517) ), and the fact that `int(Stuff.china) ` blows up and doesn't store easily in a database is the programmers issue...
-- ~Ethan~
Ethan Furman wrote:
I suppose the other option is to have `.value` be whatever was assigned (1, 'really big country', and (8273.199, 517) ),
I thought that was the intention all along, and that we'd given up on the idea of auto-assigning integer values (because it would require either new syntax or extremely dark magic).
On 04/29/2013 05:38 PM, Greg Ewing wrote:
Ethan Furman wrote:
I suppose the other option is to have `.value` be whatever was assigned (1, 'really big country', and (8273.199, 517) ),
I thought that was the intention all along, and that we'd given up on the idea of auto-assigning integer values (because it would require either new syntax or extremely dark magic).
Not that dark, actually -- just a little dim. ;)
I just had it stuck in my head that every enum item would have an integer associated with it, and possibly have another value as well.
So, for example:
--> class Constants(float, Enum): ... e = 2.81843 # am I close? ... pi = 3.141596 ... tau = 2 * pi
I cannot do
--> Constants(2)
and get pi. I have to do
--> Constants(3.141596)
and given the nature of floating point I can see that failing at some, er, point.
Likewise, if I have normal, but jumbled, Enum:
--> class Jumble(Enum): ... eggs = 1 ... method = 'scramble' ... cost = 2.5
then to get method back I have to use
--> Jumble('scramble')
It just seems odd to me. Oh, and it would seem just as odd using __getitem__. ;)
-- ~Ethan~
On Mon, Apr 29, 2013 at 5:38 PM, Greg Ewing greg.ewing@canterbury.ac.nzwrote:
Ethan Furman wrote:
I suppose the other option is to have `.value` be whatever was assigned (1, 'really big country', and (8273.199, 517) ),
I thought that was the intention all along, and that we'd given up on the idea of auto-assigning integer values (because it would require either new syntax or extremely dark magic).
Yes, Guido rejected the auto-numbering syntax a while back. The only case in which auto-numbering occurs (per PEP 435) is the "convenience syntax":
Animal = Enum('Animal', 'fox dog cat')
Eli
On 1 May 2013 02:27, Eli Bendersky eliben@gmail.com wrote:
On Mon, Apr 29, 2013 at 5:38 PM, Greg Ewing greg.ewing@canterbury.ac.nzwrote:
Ethan Furman wrote:
I suppose the other option is to have `.value` be whatever was assigned (1, 'really big country', and (8273.199, 517) ),
I thought that was the intention all along, and that we'd given up on the idea of auto-assigning integer values (because it would require either new syntax or extremely dark magic).
Yes, Guido rejected the auto-numbering syntax a while back. The only case in which auto-numbering occurs (per PEP 435) is the "convenience syntax":
Animal = Enum('Animal', 'fox dog cat')
Actually, since Guido has pronounced that definition order will be the default, there's no reason each Enum instance couldn't have an "ordinal" attribute.
Tim Delaney
On Apr 29, 2013, at 04:16 PM, Ethan Furman wrote:
I suppose the other option is to have `.value` be whatever was assigned (1, 'really big country', and (8273.199, 517) ), and the fact that `int(Stuff.china) ` blows up and doesn't store easily in a database is the programmers issue...
Correct. flufl.enum.IntEnums will blow up earlier, when the class is defined assigning the attributes to non-int values.
-Barry
On Mon, Apr 29, 2013 at 03:50:22PM -0700, Ethan Furman wrote:
This just doesn't make sense to me:
--> class Stuff(Enum): ... blue = 1 ... china = 'really big country' ... random = (8273.199, 517)
--> Stuff.blue.name == 'blue' --> Stuff.blue.value == 1
--> Stuff.china.name == 'china' --> Stuff.china.value == ???
Quoting the PEP:
"In the vast majority of use-cases, one doesn't care what the actual value of an enumeration is. But if the value is important, enumerations can have arbitrary values."
http://www.python.org/dev/peps/pep-0435/#id21
So in the above, Stuff.china.value == 'really big country' and Stuff.random.value == (8273.199, 517).
Mixing enumeration values like this would be unusual, but it will work. It's no different from having a list [1, 'really big country', (8273.199, 517)]. Lists can deal with it, but if you pass a list of arbitrary types to something that expects a list of ints, it will complain.
-
Barry Warsaw -
Eli Bendersky -
Ethan Furman -
Greg Ewing -
Steven D'Aprano -
Tim Delaney