[Python-Dev] Enumeration items: mixed types?

[Ethan Furman]

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. ;)
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com

[Ethan Furman]

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~

[Greg Ewing]

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).

--
Greg

[Barry Warsaw]

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

[Steven D'Aprano]

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.


--
Steven

[Ethan Furman]

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~

[Eli Bendersky]

On Mon, Apr 29, 2013 at 5:38 PM, Greg Ewing <greg....@canterbury.ac.nz> 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).

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

 

[Tim Delaney]

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