[Python-ideas] Enums

Spectral One ghostwriter402 at gmail.com
Fri Aug 19 23:07:03 CEST 2011

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:


enum(single) pc_make: #Declare pc_make as an enum type with the 
following contents.
     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"


from exa import 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.


> 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)

More information about the Python-ideas mailing list