A thought occurred after reading through this thread. Given that one of the most common uses of enums is to define the range of valid options to pass and to demystify such magic numbers, it seems that the proper place to have enums' variable names defined is the module in which they are declared and used, but in cases where the meaning is clear, and only there, pull them out. (that is, normally, one needs to type "EnumInstanceName.Code" e.g. "Colors.red", but when in a place where the author specified a specific enum, the code is all that's required. e.g. "red") After all, unless someone wants to allow MULTIPLE enums as an argument, the normal collision rules should prevent most of the problems. This should work for either the single-value or multiple value cases, since it merely imports the namespace, and the parser otherwise works as normal. (Such importation would need to override, and pull from the enum, wherever it's called from.) I suppose this could be a general soft-typing syntax, and the Enum object type could simply be a valid instance, but I don't think I like that notion. I'd prefer the syntax to be clearly a set enumeration. Of course, I'd also like some fast and easy way of declaring whether the enum in question should allow aggregate/composite types, or singular values from the list, with an exception raised on failure to comply. something like the following: #exa.py: enum(single) pc_make: #Declare pc_make as an enum type with the following contents. apple ibm=2.5 atari="Just to demonstrate non-numeric" #I picture defaulting to unique, non-overlapping integer values, unless otherwise defined. #Valid types would best be hashable #I suppose "pc_make=enum(single)" is more consistent, if we think of enum as a class, #Also, enum(1) might be better, for defining values accepted. I digress. def Box: def SetMake( new_make:enum(pcmake)=ibm ): #to set the id to "new_make", the enum to pcmake, and the default setting to "ibm" pass #2nd_module.py: from exa import Box b=Box() b.SetMake(apple) #Works fine b.SetMake(ibm + apple) $Raises an enum_error, since the enum was declared singular. (In hindsight, the argument definition is a better place to to define the singular/multiple values option, though having the ability to defining once for all would make use easier.) Hopefully the idea is clear. The repr(enum_code)='enum_code' notion would certainly be compatible. -Nate

That's assuming the data export format doesn't support enums.

I would fine enums whose str() is just an int pretty annoying. Note that str(True) == repr(True) == 'True' and that's how I'd like it to be for enums in general. If you want the int value, use int(e). If you want the class name, use e.__class__.__name__ (maybe e.__class__ is what you're after anyway). My observation is that most enums have sufficiently unique names that during a debugging session the class is not a big mystery; it's the mapping from value to name that's hard to memorize. As a compromise, I could live with str(e) == 'red' and repr(e) == 'Color.red'. But I don't think I could stomach str(e) == 1.

-- --Guido van Rossum (python.org/~guido)