Antoine Pitrou added the comment:
> JSON has to be taught how to serialize enums. Of course, it also has
> to be
> taught how to serialize datetimes, timedeltas, and other common data
> types.
How so? The point of IntEnum was that it derived from int, and therefore
would avoid any need for spec
Barry A. Warsaw added the comment:
On Jun 19, 2013, at 01:48 PM, Nick Coghlan wrote:
>I created issue 18264 after I tried it and found my theoretical concern
>wasn't theoretical at all: swapping a true integer for the current
>incarnation of enum.IntEnum breaks (at least) JSON serialisation, whi
Nick Coghlan added the comment:
I created issue 18264 after I tried it and found my theoretical concern wasn't
theoretical at all: swapping a true integer for the current incarnation of
enum.IntEnum breaks (at least) JSON serialisation, which means we can't use it
in its current form to replac
Barry A. Warsaw added the comment:
On Jun 19, 2013, at 06:45 AM, Ethan Furman wrote:
>To sum up: the name is already available in the name, no need to have it be
>the value as well. I am open to changing the start value to zero instead of
>one (which is what I do in my customization of Enum in
Barry A. Warsaw added the comment:
On Jun 19, 2013, at 01:00 PM, Eli Bendersky wrote:
>What is the theoretical problem here? I though that it's an explicit design
>goal of enums? Which RED - Color.RED, or MeatReadiness.RED? For sockets:
>
class SocketType(IntEnum):
>... SOCK_STREAM = 1
>.
Eli Bendersky added the comment:
> The fact "str(x)" returns the fully qualified name for IntEnum worries me a
> bit, but if there's a real backwards compatibility problem there (rather than
> a theoretical one), hopefully we'll see it once we start converting socket
> and errno.
What is the
Eli Bendersky added the comment:
Nicely done summary, Ethan.
I think it would be worthwhile to add the reasoning of "why from 1 and not from
0" into the documentation and maybe the PEP too. I think the "falsiness" answer
is reasonable, and since it's a common FAQ it's good to state it explicit
Nick Coghlan added the comment:
OK, I've satisfied myself that the current behaviour is reasonable, and it's
specifically the subclassing behaviour of the status quo that works for me.
1. You have to specifically access the "x.value" attribute of a default enum
member to see it. "str(x)" shows
Ethan Furman added the comment:
Enum members have two pieces of easily accessible information: `name` and
`value`. The name is taken from the attribute the value is assigned to; the
value, obviously, is the value assigned.
The question, then, is what should happen when the function syntax is
