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 rep...@bugs.python.org
http://bugs.python.org/issue17961
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?
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 tracker
Nick Coghlan added the comment:
On 14 May 2013 00:06, Antoine Pitrou rep...@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()?
Ethan Furman added the comment:
So the repr will look like:
Color.red: 'red'
?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17961
___
___
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()?
Because strings are
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() and
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
Changes by Nick Coghlan ncogh...@gmail.com:
--
dependencies: +Code, test, and doc review for PEP-0435 Enum
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17961
___
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17961
___
___
Python-bugs-list
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
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
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17961
___
___
Python-bugs-list mailing
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 definition
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 rep...@bugs.python.org
http://bugs.python.org/issue17961
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
16 matches
Mail list logo
