The only purposes of an enum that pop to my mind are: Specifying allowed values, the better to limit input to valid choices Assigning mnemonic indeces. the better to remember how to call something These can be independent of each other. When the actual allowed values are based off of operations using the mnemonics, (e.g. ANDing the values , which are all powers of two.) the actual values are not limited to the set, but rather to a linear combination of the set. That's significantly different from a specific set of options. (in which the meaning is based off of the selection, and not the result. e.g. Cardinal directions: {Up, Down, Left,Right}) In the case where the mnemonic is a single option form a set, it would be good to be able to pull the index value back out from the value passed. One could approximate this behavior by providing a constant set inside the appropriate namespace, which contains tuples of the values and their keys inside a dictionary. (or whatever is more efficient. I'm still new at Python, so I'm not sure how, if it's even possible, to extract an index string from a dictionary.) The value actually passed is whatever the object stored in that tuple would be, which could be an honest integer, if that mattered. Come to think of it, pulling the set of values that defined the entry as, for example, a list or iterable, would be really useful some times, as well. At any rate, what occurs to me is that enums are trying to fill a couple roles at once and that seems to be what makes their 'proper' behavior hard to define. A 2-way index pair structure handles most everything I see enums providing when used as unordered values. That way the recipient code can easily analyze the value entered and UIs can easily provide the mnemonic (whether authoring or debugging) which assists a user of a library and that library's author in coordinating. As to the composite case, well, the most common I've seen is a composite of powers of two. That sort of thing could assign values to bits, and may include multiple mnemonics for specific patterns. Again, not terribly complex to think about, though someone would need to decide whether composite or specific bit patterns dominate when they overlap, if the structure is to spit the values back out. Patterns impossible to generate should be rejected as such, since that's rather the point of such a structure. The composite value should probably spit out as an integer, though whether a fixed size or python's flexible length integer, signed or unsigned, and so forth are not options I've pondered. As noted, the scope of these objects should work like pretty much any array type with, no new scoping rules required.