Use enum names as values in enum.Enum() functional API

[ncoghlan]

BPO	17961
Nosy	@warsaw, @ncoghlan, @pitrou, @ethanfurman
Dependencies	bpo-17947: Code, test, and doc review for PEP-0435 Enum

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/ethanfurman'
closed_at = <Date 2013-06-19.11:32:02.004>
created_at = <Date 2013-05-12.10:57:02.123>
labels = ['type-feature']
title = 'Use enum names as values in enum.Enum() functional API'
updated_at = <Date 2013-06-19.14:07:53.388>
user = 'https://github.com/ncoghlan'

bugs.python.org fields:

activity = <Date 2013-06-19.14:07:53.388>
actor = 'pitrou'
assignee = 'ethan.furman'
closed = True
closed_date = <Date 2013-06-19.11:32:02.004>
closer = 'ncoghlan'
components = []
creation = <Date 2013-05-12.10:57:02.123>
creator = 'ncoghlan'
dependencies = ['17947']
files = []
hgrepos = []
issue_num = 17961
keywords = []
message_count = 25.0
messages = ['189013', '189022', '189023', '189067', '189072', '189085', '189087', '189088', '189094', '189115', '189132', '189135', '189137', '189140', '189142', '189143', '191449', '191460', '191462', '191464', '191465', '191466', '191468', '191469', '191472']
nosy_count = 5.0
nosy_names = ['barry', 'ncoghlan', 'pitrou', 'eli.bendersky', 'ethan.furman']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue17961'
versions = ['Python 3.4']

[ncoghlan]

I encountered an interesting suggestion [1] regarding the enum.Enum convenience API: use the member names as their values, rather than the current integers starting from one.

Since we're now using definition order rather than value order for iteration, this suggestion makes a lot of sense to me.

(again, posting this as something to consider after the accepted PEP is incorporated)

[1] http://www.acooke.org/cute/Pythonssad0.html

[ncoghlan]

Specifically, my suggestion is that for auto-created enum members, the invariant "asset x.value == str(x)" should hold.

In flufl.enum, using integers made sense because it relies on sorting of values to determine the iteration order. That's no longer a concern for the standard library version, as iteration has been changed to use definition order.

[ethanfurman]

In flufl.enum integers also made since as that was the default back-end data type.

Currently, the functional method allows a type declaration. The behavior there could be tweaked such that no specification meant no value (a truly valueless enum!), type=int means ints starting from 1, type=str meant str values of names, any other value and you better had made your own enum derived class to support it.

[warsaw]

On May 12, 2013, at 10:57 AM, Nick Coghlan wrote:

I encountered an interesting suggestion [1] regarding the enum.Enum
convenience API: use the member names as their values, rather than the
current integers starting from one.

Since we're now using definition order rather than value order for iteration,
this suggestion makes a lot of sense to me.

Cute, but I want the functional API to be equivalent to the class syntax.

Besides:

X = Enum('X', ((name, name) for name in 'ant bee cat dog elk'.split()))

is not so much typing.

[ncoghlan]

That gives the unqualified names, and I don't understand your other
objection. The class syntax doesn't support implicit values at all.

[ethanfurman]

The class syntax (and default Enum) no longer have preferential treatment for integers (even __int__ is gone); so it is completely up to us as what should happen for the functional syntax.

[warsaw]

On May 12, 2013, at 8:35 PM, Ethan Furman wrote:

Ethan Furman added the comment:

The class syntax (and default Enum) no longer have preferential treatment for integers (even __int__ is gone); so it is completely up to us as what should happen for the functional syntax.

Do you really think the enum discussion on python-dev was too short and could use another few thousand messages? ;)

Or IOW, hasn't this already been decided by virtue of PEP acceptance?

[ethanfurman]

On 05/12/2013 06:57 PM, Barry A. Warsaw wrote:

Do you really think the enum discussion on python-dev was too short and could use another few thousand messages? ;)

No!

Or IOW, hasn't this already been decided by virtue of PEP acceptance?

Indeed it has. I was merely replying to your comment about keeping class and function syntax in sync, when in fact
there is no longer any direct correlation between the two other than the names used and the type created.

[ncoghlan]

Accepting awkward implementation details when their rationale no longer
applies doesn't make sense to me, no.

The functional API originally used integers for good reasons. Over the
course of the enum discussions, those reasons evaporated, but this wasn't
noticed until after the PEP was accepted.

However, the acceptance of the PEP is why I have proposed this as a
post-incorporation change.

[pitrou]

I agree with Nick here, there's no reason to auto-number constants in Python. This is not C :-)

[warsaw]

On May 13, 2013, at 10:10 AM, Antoine Pitrou wrote:

I agree with Nick here, there's no reason to auto-number constants in
Python. This is not C :-)

Why should they be strings? Why not object()?

Why is x.value == str(x) a useful invariant to hold?

[pitrou]

>I agree with Nick here, there's no reason to auto-number constants
>in
>Python. This is not C :-)

Why should they be strings? Why not object()?

Because strings are readable, I'd say.

[ncoghlan]

On 14 May 2013 00:06, "Antoine Pitrou" <report@bugs.python.org> wrote:

Antoine Pitrou added the comment:

> >I agree with Nick here, there's no reason to auto-number constants
> >in
> >Python. This is not C :-)
>
> Why should they be strings? Why not object()?

Because strings are readable, I'd say.

Yep. Since we no longer have a compelling reason for it to be anything
else, it may as well be the human readable string.

[ethanfurman]

So the repr will look like:

<Color.red: 'red'>

?