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).
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.
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.
That's not an entirely fair way to put it, Raymond. Yes, some folks said that maybe Python doesn't need enums at all. But many more said Enums should get into Python, including Guido. The issue was sealed in a face-to-face discussion during the recent PyCon language summit in which many core devs participated. So presenting this as some evil ploy to "drown the opposition" in a flood of email is... unfair.
Naturally I participated in the discussion, but the vast majority of emails I sent was to steer it long after the decision to add some kind of enumeration was made.
It depends. In our code we have constants integers used as kinds marker that get stored in database. Messing them would break things bad. And we have them everywhere. And we have maybe over a thousand of them.
Had we had this enum from the beginning we would now probably have a code base in a slightly but significantly better shape.
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.
>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,
Because if you read the function signature of a function like def fill_rectangle(color) you haven't got the slightest idea what valid values of "color" is. (Ignore the fact that python doesn't have types in the function signature to start with, say you're reading the documentation instead)
If you knew that color was of the enum-type my_gui_lib.standard_colors you know exactly which colors you can use and you can reuse them for fill_ellipse also because it most likely uses the same type. Instead of every function having to reiterate all valid integer values of color or referring to some table. Your editor will also provide you with auto complete of valid values unless you're coding in notepad.
In a type safe language you will even get compilation error if you provide a type/value out of range but since python is dynamic this would be hard. It's simply impossible to pass the function an invalid value, which is invaluable. So in python the value added isn't a strong as in a strong language but it's still there.
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.
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.
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.
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).