[issue17961] Use enum names as values in enum.Enum convenience API

Barry A. Warsaw added the comment: On May 13, 2013, at 02:24 PM, Nick Coghlan wrote: >Yep. Since we no longer have a compelling reason for it to be anything >else, it may as well be the human readable string. Again, why does it matter? That's the whole point of having a human readable str() an

[issue17961] Use enum names as values in enum.Enum convenience API

Barry A. Warsaw added the comment: On May 13, 2013, at 02:06 PM, Antoine Pitrou 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()? > >Becaus

[issue17961] Use enum names as values in enum.Enum convenience API

Ethan Furman added the comment: So the repr will look like: ? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue17961] Use enum names as values in enum.Enum convenience API

Nick Coghlan added the comment: On 14 May 2013 00:06, "Antoine Pitrou" 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()? > > Becau

[issue17961] Use enum names as values in enum.Enum convenience API

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. -- ___ Python track

[issue17961] Use enum names as values in enum.Enum convenience API

Barry A. Warsaw added the comment: 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? -

[issue17961] Use enum names as values in enum.Enum convenience API

Antoine Pitrou added the comment: I agree with Nick here, there's no reason to auto-number constants in Python. This is not C :-) -- nosy: +pitrou ___ Python tracker ___ ___

[issue17961] Use enum names as values in enum.Enum convenience API

Nick Coghlan added the comment: 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 u

[issue17961] Use enum names as values in enum.Enum convenience API

Ethan Furman added the comment: 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.

[issue17961] Use enum names as values in enum.Enum convenience API

Barry A. Warsaw added the comment: 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 t

[issue17961] Use enum names as values in enum.Enum convenience API

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. -- ___ Python tracker

[issue17961] Use enum names as values in enum.Enum convenience API

Nick Coghlan added the comment: That gives the unqualified names, and I don't understand your other objection. The class syntax doesn't support implicit values at all. -- ___ Python tracker

[issue17961] Use enum names as values in enum.Enum convenience API

Barry A. Warsaw added the comment: 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 definiti

[issue17961] Use enum names as values in enum.Enum convenience API

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue17961] Use enum names as values in enum.Enum convenience API

Ethan Furman added the comment: 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 mea

[issue17961] Use enum names as values in enum.Enum convenience API

Nick Coghlan added the comment: 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 f

[issue17961] Use enum names as values in enum.Enum convenience API

Changes by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue17961] Use enum names as values in enum.Enum convenience API

Changes by Nick Coghlan : -- dependencies: +Code, test, and doc review for PEP-0435 Enum versions: +Python 3.4 ___ Python tracker ___

[issue17961] Use enum names as values in enum.Enum convenience API

New submission from Nick Coghlan: 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 s