Reading this thread it seems that many core devs are interested in the
feature and the discussion is mainly deciding on the exact semantics and implementation. Even Guido didn't really speak against it (only somewhat against adding new syntax).
Eli
Personally I'm -1 for a variety of reasons.
1) a const/enum type looks like something which is subject to personal taste to me. I personally don't like, for example, how flufl requires to define constants by using a class. It's just a matter of taste but to me module.FOO looks more "right" than module.Bar.FOO. Also "Colors.red < Colors.blue" raising an exception is something subject to personal taste.
2) introducing something like that (class-based) wouldn't help migrating the existent module-level constants we have in the stdlib. Only new projects or new stdlib modules would benefit from it.
These are more in the domain of implementation details, though, not criticizing the concep?
3) other than being subject to personal taste, a const/enum type is also pretty easy to implement. For example, I came up with this:
http://code.google.com/p/psutil/source/browse/trunk/psutil/_common.py?spec=svn1562&r=1524#33 ...which is sufficient for my needs. Users having different needs can do a similar thing pretty easily.
It is precisely *because* every library defines its own way to create enums that IMHO we should have them in the language (or in the standard library, at the least).
4) I'm getting the impression that the language is growing too big. To me, this looks like yet another thing that infrequent users have to learn before being able to read and understand Python code. Also consider that people lived without const/enum for 2 decades now.
I respectfully disagree. Most folks seem to favor a library solution (i.e. no new syntax, just a new metaclass+class to use). The stdlib has tools for very obscure things. In comparison, enum is something almost every non-trivial program needs to use at some stage or another. Eli