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
atari="Just to demonstrate non-numeric"
#I picture defaulting to unique, non-overlapping integer values, unless
#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 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
(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