Guido van Rossum writes:
Frankly, enums are not that useful in small programs.
This seems like a very personal thing to me. In some sense that I suppose can be made as objective as counting keystrokes[1], I have to agree with you. But I don't feel that Steven's cringing at "magic literals" is a less valid argument for supporting a particular syntax than your cringing at "quoted identifier names". Of course, technically speaking, Steven could perfectly well use "explicit-valued" enums[2] to eliminate magic literals. But from a beautiful language perspective, ISTM that he is just one among many to advocate that an enum *definition* should look like an *unordered list of identifiers*.[3] It's not about keystroke count, it's about correspondence of syntax to semantics. He's not doing himself any favors by replacing a few magic literals with a hard to read, overdefined enum declaration. I strongly suspect that if you put explicit-valued enums into the stdlib now, you will find that there remains a strong demand for "nice" enums as Tim calls them (although most RFEs will probably use the word "real"!) Footnotes: [1] But far more important, I grant you that. ;-) [2] Note that EIBTI is *not* an argument for explicit-valued enums, because an enum elements's name and class should tell you everything you need to know about its semantics. If it doesn't, you aren't using it as an enum! And "YELLOW = val()" is hardly explicit. :-( [3] If that "list" of names actually has more structure (a set that allows subsetting and union as commonly done with flags, or an order such as the spectrum of colors), it would be nice if that structure is imposed automatically as well -- but this should be done by a subclass such as OrderedEnum or FlagEnum which makes the structure explicit.