7 ms·

I think the author is sad for the wrong reason. Syntactic nitpicking is bikeshedding. Remember, Guido makes choices that may not be obvious unless you're Dutc

I think the author is sad for the wrong reason. Syntactic nitpicking is bikeshedding. Remember, Guido makes choices that may not be obvious unless you're Dutch, but he has a pretty good track record overall. A better critique would focus on whether the language actually needed an Enum construct. Most people get by most of the time without it. Python already provides many ways to do it (module variables, class variables, etc). The main problem with Enum is that you won't be able to ignore it. Enums will start popping-up in many modules and packages, so it will have to become part of your core Python knowledge (things you have to teach to beginners so they can work with existing code). Contrast that with named tuples. They can be ignored (i.e. you can treat them like regular tuples and you'll get by just fine). Also, named tuples are profoundly more useful (i.e. using them is one of the easiest ways to improve the clarity of your code).

digisign 13y ago
Here, here. Been trying to come up with a reason to use these over named tuples but they are few.
- eliben 13y ago
  If you can't distinguish between enumerations and named tuples, I think you have a bigger problem than you think. I mean this in full seriousness. Conceptually, the two constructs have completely different uses. That you can twist and bend one to implement a faint shadow of the other doesn't mean they are the same.
  - goostavos 13y ago
    >Conceptually, the two constructs have completely different uses. I'm not the one you replied to, and it's tough to not sound sarcastic on the internet, but I'm honestly curious what the purpose of an Enum type is. I didn't really get their purpose when I took Java I, and I don't really see why Python needs them. What is the advantage of declaring an Enum vs something like, VALUE_ONE, VALUE_TWO, VALUE_THREE = range(3) ?
    - Elv13 13y ago
      In C/C++, with you use an enum type in a switch, the compiled will warn you if you are missing one. If you pass an enum type as argument, there will be a compile time check if the constant is part of the enum (you can force them, but it is not the point). Having a grouped set of constants also make sense in an organizational POV. In Java, enums are classes while in C/C++ they are only a set of constants. Enums in different languages are implemented differently and have various kind of extra features. But deep down, they always serve the purpose of storing a related set of constants.
    - scott_s 13y ago
      To expand on what the other poster said: VALUE_ONE, VALUE_TWO and VALUE_THREE are ints. That is their type. In most cases, though, groups of constants have some conceptual type that is entirely separate from integers. It's nice to formalize that concept in our code with an actual type. That way, when we say a function accept that type, we can't also pass it a random integer. Or returns that type, we can't return a random integer.
      - thaumasiotes 13y ago
        Isn't it one of the core Python values that functions don't contract to accept, or return, particular types at all?
        ansgri 13y ago
        There's no enforced contract for a particular type, but a way to create entirely new values that have no relation to any existing value. I.e. you compare a value to MyEnum.SpecialUndefined and are sure that no None or 0 will yield True. OTOH, if someone would be determined to create a thing with the same conceptual sense as SpecialUndefined, he could explicitly define that it is Equal to MyEnum.SpecialUndefined.
    - eliben 13y ago
      There are many advantages. Here are some: >>> class MyEnum(Enum): ... VALUE_ONE, VALUE_TWO, VALUE_THREE = range(3) ... >>> v = MyEnum.VALUE_ONE >>> v == 0 False >>> v == MyEnum.VALUE_ONE True >>> type(v) <enum 'MyEnum'> >>> isinstance(v, MyEnum) True >>> print(v) MyEnum.VALUE_ONE >>> Now try to think how these would result if you'd defined VALUE_ONE... your way.
eliben 13y ago
And yet most large Python projects reinvent the concept of enums in one way or another. This includes Python itself, where enums could be used in many places in the stdlib. Actually, one of the main reasons IntEnum is part of the implementation is that it will be possible to replace stdlib constants with it (for example some socket.* and io.* constants). This was discussed in the mailing list in the past, and I even had a prototype of CPython with constants replaced by IntEnum. Due to its being an actual int it retains backwards compatibility while providing very nice printable representation for the constants.
- raymondh 13y ago
  Clearly, you're a big proponent of Enums needing to be in Python (I would estimate that you've made several hundred emails, comments, and posts on the subject). You and a couple other vociferous proponents completely drown-out the early commenters who valued language compactness and learnability over a pervasive new construct that solves a somewhat unimportant problem. The fact that some large projects may have a use for Enums wasn't balanced against an impending avalanche of Enums being sprinkled in beginner code, small projects, recipes, etc. I expect the use of Enums will become pervasive simply because they're there, not because a given snippet of code actually needs it. As a person who teaches Python to engineers, I dread adding yet another have-to-know construct to the cirriculum. Python is no longer a small language. Also, there is a lot of machinery behind Enums (killing a mosquito with a cannon). So, we should expect that people will hack it, abuse it, twist it into knots, subclass it, invent tricks will it, develop funky idioms, etc. IMO, none of this is worth it. The "problem" wasn't that important to begin with. That said, the discussion is moot. There is no need to defend the proposal any more. Guido has accepted the PEP and it will enter the language, for better or for worse. If we had to have a Enum, the one that was accepted was a reasonable choice. For the most part, the discussion did a nice job of considering existing recipes, possible use cases, and being as Pythonic as possible. My only criticism of the process is that handful of enthusiasts (Eli, Ethan, Barry, etc) launched an avalanche of implementation and api-choice emails that buried and ignored the posts suggesting the language would be better-off without Enum. AFAICT, there was no honest discussion of simply establishing best practices using existing tools.
kami8845 13y ago
>Also, named tuples are profoundly more useful (i.e. using them is one of the easiest ways to improve the clarity of your code). I read that and I thought, "that's such a thing Raymond Hettinger would say". Then I glanced up at the username :)
qxcv 13y ago
> A better critique would focus on whether the language actually needed an Enum construct. This isn't a new construct, or a syntax change, or an additional builtin. It's just an addition to the stdlib so that you can go: from enum import Enum ...which isn't quite as earth-shattering as some people in this thread are making out.
- deleted 13y ago
  [deleted]

digisign 13y ago

Here, here. Been trying to come up with a reason to use these over named tuples but they are few.

eliben 13y ago
If you can't distinguish between enumerations and named tuples, I think you have a bigger problem than you think. I mean this in full seriousness. Conceptually, the two constructs have completely different uses. That you can twist and bend one to implement a faint shadow of the other doesn't mean they are the same.
- goostavos 13y ago
  >Conceptually, the two constructs have completely different uses. I'm not the one you replied to, and it's tough to not sound sarcastic on the internet, but I'm honestly curious what the purpose of an Enum type is. I didn't really get their purpose when I took Java I, and I don't really see why Python needs them. What is the advantage of declaring an Enum vs something like, VALUE_ONE, VALUE_TWO, VALUE_THREE = range(3) ?
  - Elv13 13y ago
    In C/C++, with you use an enum type in a switch, the compiled will warn you if you are missing one. If you pass an enum type as argument, there will be a compile time check if the constant is part of the enum (you can force them, but it is not the point). Having a grouped set of constants also make sense in an organizational POV. In Java, enums are classes while in C/C++ they are only a set of constants. Enums in different languages are implemented differently and have various kind of extra features. But deep down, they always serve the purpose of storing a related set of constants.
  - scott_s 13y ago
    To expand on what the other poster said: VALUE_ONE, VALUE_TWO and VALUE_THREE are ints. That is their type. In most cases, though, groups of constants have some conceptual type that is entirely separate from integers. It's nice to formalize that concept in our code with an actual type. That way, when we say a function accept that type, we can't also pass it a random integer. Or returns that type, we can't return a random integer.
    - thaumasiotes 13y ago
      Isn't it one of the core Python values that functions don't contract to accept, or return, particular types at all?
      - ansgri 13y ago
        There's no enforced contract for a particular type, but a way to create entirely new values that have no relation to any existing value. I.e. you compare a value to MyEnum.SpecialUndefined and are sure that no None or 0 will yield True. OTOH, if someone would be determined to create a thing with the same conceptual sense as SpecialUndefined, he could explicitly define that it is Equal to MyEnum.SpecialUndefined.
  - eliben 13y ago
    There are many advantages. Here are some: >>> class MyEnum(Enum): ... VALUE_ONE, VALUE_TWO, VALUE_THREE = range(3) ... >>> v = MyEnum.VALUE_ONE >>> v == 0 False >>> v == MyEnum.VALUE_ONE True >>> type(v) <enum 'MyEnum'> >>> isinstance(v, MyEnum) True >>> print(v) MyEnum.VALUE_ONE >>> Now try to think how these would result if you'd defined VALUE_ONE... your way.

eliben 13y ago

And yet most large Python projects reinvent the concept of enums in one way or another. This includes Python itself, where enums could be used in many places in the stdlib. Actually, one of the main reasons IntEnum is part of the implementation is that it will be possible to replace stdlib constants with it (for example some socket.* and io.* constants). This was discussed in the mailing list in the past, and I even had a prototype of CPython with constants replaced by IntEnum. Due to its being an actual int it retains backwards compatibility while providing very nice printable representation for the constants.

raymondh 13y ago
Clearly, you're a big proponent of Enums needing to be in Python (I would estimate that you've made several hundred emails, comments, and posts on the subject). You and a couple other vociferous proponents completely drown-out the early commenters who valued language compactness and learnability over a pervasive new construct that solves a somewhat unimportant problem. The fact that some large projects may have a use for Enums wasn't balanced against an impending avalanche of Enums being sprinkled in beginner code, small projects, recipes, etc. I expect the use of Enums will become pervasive simply because they're there, not because a given snippet of code actually needs it. As a person who teaches Python to engineers, I dread adding yet another have-to-know construct to the cirriculum. Python is no longer a small language. Also, there is a lot of machinery behind Enums (killing a mosquito with a cannon). So, we should expect that people will hack it, abuse it, twist it into knots, subclass it, invent tricks will it, develop funky idioms, etc. IMO, none of this is worth it. The "problem" wasn't that important to begin with. That said, the discussion is moot. There is no need to defend the proposal any more. Guido has accepted the PEP and it will enter the language, for better or for worse. If we had to have a Enum, the one that was accepted was a reasonable choice. For the most part, the discussion did a nice job of considering existing recipes, possible use cases, and being as Pythonic as possible. My only criticism of the process is that handful of enthusiasts (Eli, Ethan, Barry, etc) launched an avalanche of implementation and api-choice emails that buried and ignored the posts suggesting the language would be better-off without Enum. AFAICT, there was no honest discussion of simply establishing best practices using existing tools.

kami8845 13y ago

>Also, named tuples are profoundly more useful (i.e. using them is one of the easiest ways to improve the clarity of your code). I read that and I thought, "that's such a thing Raymond Hettinger would say". Then I glanced up at the username :)

qxcv 13y ago

> A better critique would focus on whether the language actually needed an Enum construct. This isn't a new construct, or a syntax change, or an additional builtin. It's just an addition to the stdlib so that you can go: from enum import Enum ...which isn't quite as earth-shattering as some people in this thread are making out.

deleted 13y ago
[deleted]