On 04/29/2013 03:13 PM, Guido van Rossum wrote:

Only if it is easy to implement. This example doesn't look like a good fit for enums, but if the enum implementation can easily support this (e.g. if there's nothing special about __init__) I don't want to forcibly rule it out. I don't want to have to bend over backwards to support it, however, if it causes problems for the implementation.

Beautiful answer. :) -- ~Ethan~

On 04/29/2013 03:25 PM, Eli Bendersky wrote:

On Mon, Apr 29, 2013 at 2:59 PM, Ethan Furman wrote:

...

In the Planet example we saw the possibility of specifying arguments to enum item __init__:

class Planet(Enum): MERCURY = (3.303e+23, 2.4397e6) VENUS = (4.869e+24, 6.0518e6) EARTH = (5.976e+24, 6.37814e6) MARS = (6.421e+23, 3.3972e6) JUPITER = (1.9e+27, 7.1492e7) SATURN = (5.688e+26, 6.0268e7) URANUS = (8.686e+25, 2.5559e7) NEPTUNE = (1.024e+26, 2.4746e7)

def __init__(self, mass, radius): self.mass = mass # in kilograms self.radius = radius # in meters

Do we want to support this?

I'm -1, and this is yet another bad sign of conflating enums with classes. If planets want to have attributes and behaviors, let them be normal classes. If they want a PlanetId *enum member*, that's OK, but there's no need to intermix the two.

Besides, did we not agree that the only acceptable *members* for enums are going to be descriptors? In the above, mass & radius are not descriptors.

Good point. We can leave that out, then. -- ~Ethan~

On 04/29/2013 03:25 PM, Eli Bendersky wrote:

Besides, did we not agree that the only acceptable *members* for enums are going to be descriptors? In the above, mass & radius are not descriptors.

Actually, it's the other way -- descriptors are excluded from being enum items, along with dunders. -- ~Ethan~

On Apr 29, 2013, at 3:25 PM, Eli Bendersky wrote:

On Mon, Apr 29, 2013 at 2:59 PM, Ethan Furman <ethan@stoneleaf.us> wrote: In the Planet example we saw the possibility of specifying arguments to enum item __init__:

class Planet(Enum): MERCURY = (3.303e+23, 2.4397e6) VENUS = (4.869e+24, 6.0518e6) EARTH = (5.976e+24, 6.37814e6) MARS = (6.421e+23, 3.3972e6) JUPITER = (1.9e+27, 7.1492e7) SATURN = (5.688e+26, 6.0268e7) URANUS = (8.686e+25, 2.5559e7) NEPTUNE = (1.024e+26, 2.4746e7)

def __init__(self, mass, radius): self.mass = mass # in kilograms self.radius = radius # in meters

Do we want to support this?

I'm -1, and this is yet another bad sign of conflating enums with classes. If planets want to have attributes and behaviors, let them be normal classes. If they want a PlanetId *enum member*, that's OK, but there's no need to intermix the two.

You may be right about the Planet example, but I wouldn't go that far. Additional metadata on Enum instances can be a handy feature in some cases, like documentation, e.g.: class Protocol(Enum): HOPOPT = 0, "IPv6 Hop-by-Hop Option" ICMP = 1, "Internet Control Message" IGMP = 2, "Internet Group Management" @property def value(self): return self._value[0] @property def description(self): return self._value[1] -- Philip Jenvey

On Apr 29, 2013, at 03:25 PM, Eli Bendersky wrote:

I'm -1, and this is yet another bad sign of conflating enums with classes. If planets want to have attributes and behaviors, let them be normal classes. If they want a PlanetId *enum member*, that's OK, but there's no need to intermix the two.

I agree with this. -Barry

On 04/29/2013 03:13 PM, Guido van Rossum wrote:

Only if it is easy to implement. This example doesn't look like a good fit for enums, but if the enum implementation can easily support this (e.g. if there's nothing special about __init__) I don't want to forcibly rule it out. I don't want to have to bend over backwards to support it, however, if it causes problems for the implementation.

Beautiful answer. :) -- ~Ethan~

On 04/29/2013 03:25 PM, Eli Bendersky wrote:

On Mon, Apr 29, 2013 at 2:59 PM, Ethan Furman wrote:

...

In the Planet example we saw the possibility of specifying arguments to enum item __init__:

class Planet(Enum): MERCURY = (3.303e+23, 2.4397e6) VENUS = (4.869e+24, 6.0518e6) EARTH = (5.976e+24, 6.37814e6) MARS = (6.421e+23, 3.3972e6) JUPITER = (1.9e+27, 7.1492e7) SATURN = (5.688e+26, 6.0268e7) URANUS = (8.686e+25, 2.5559e7) NEPTUNE = (1.024e+26, 2.4746e7)

def __init__(self, mass, radius): self.mass = mass # in kilograms self.radius = radius # in meters

Do we want to support this?

I'm -1, and this is yet another bad sign of conflating enums with classes. If planets want to have attributes and behaviors, let them be normal classes. If they want a PlanetId *enum member*, that's OK, but there's no need to intermix the two.

Besides, did we not agree that the only acceptable *members* for enums are going to be descriptors? In the above, mass & radius are not descriptors.

Good point. We can leave that out, then. -- ~Ethan~

On 04/29/2013 03:25 PM, Eli Bendersky wrote:

Besides, did we not agree that the only acceptable *members* for enums are going to be descriptors? In the above, mass & radius are not descriptors.

Actually, it's the other way -- descriptors are excluded from being enum items, along with dunders. -- ~Ethan~

On Apr 29, 2013, at 3:25 PM, Eli Bendersky wrote:

On Mon, Apr 29, 2013 at 2:59 PM, Ethan Furman <ethan@stoneleaf.us> wrote: In the Planet example we saw the possibility of specifying arguments to enum item __init__:

class Planet(Enum): MERCURY = (3.303e+23, 2.4397e6) VENUS = (4.869e+24, 6.0518e6) EARTH = (5.976e+24, 6.37814e6) MARS = (6.421e+23, 3.3972e6) JUPITER = (1.9e+27, 7.1492e7) SATURN = (5.688e+26, 6.0268e7) URANUS = (8.686e+25, 2.5559e7) NEPTUNE = (1.024e+26, 2.4746e7)

def __init__(self, mass, radius): self.mass = mass # in kilograms self.radius = radius # in meters

Do we want to support this?

I'm -1, and this is yet another bad sign of conflating enums with classes. If planets want to have attributes and behaviors, let them be normal classes. If they want a PlanetId *enum member*, that's OK, but there's no need to intermix the two.

You may be right about the Planet example, but I wouldn't go that far. Additional metadata on Enum instances can be a handy feature in some cases, like documentation, e.g.: class Protocol(Enum): HOPOPT = 0, "IPv6 Hop-by-Hop Option" ICMP = 1, "Internet Control Message" IGMP = 2, "Internet Group Management" @property def value(self): return self._value[0] @property def description(self): return self._value[1] -- Philip Jenvey

On Apr 29, 2013, at 03:25 PM, Eli Bendersky wrote:

I'm -1, and this is yet another bad sign of conflating enums with classes. If planets want to have attributes and behaviors, let them be normal classes. If they want a PlanetId *enum member*, that's OK, but there's no need to intermix the two.

I agree with this. -Barry