Behaviour of enumerated types

[Ben Finney]

Bengt Richter <bokr at oz.net> wrote:
> On Sat, 19 Nov 2005 11:10:42 +1100 (EST), Ben Finney <bignose+hates-spam at benfinney.id.au> wrote:
> >Bengt Richter <bokr at oz.net> wrote:
> >> If [an enumeration has a fixed sequence], what is more natural
> >> than using their index values as keys to other ordered info?
> >I don't see why. If you want sequence numbers, use enumerate(). If
> >not, the enum object itself can be used directly as an iterable.
>
> I changed mine so the enum _class_ is iterable, but enum instances
> are not.

I'm not really understanding your design.

In my enum package, an enumeration is an instance of Enum. Those
instances are iterable, producing EnumValue instances; the EnumValue
instances are also available as named attributes of the Enum instance.

    >>> from enum import Enum
    >>> colours = Enum('red', 'blue', 'green')
    >>> for val in colours:
    ...     print str(val)
    ...
    red
    blue
    green

Why would the Enum *class* be iterable?

> >> OTOH, the index values (and hence my enums) are[1] not very good
> >> as unique dict keys, since they compare[2] promiscuously with
> >> each other and other number types.
> >Indeed, that's why (in my design) the values from the enum are only
> >useful for comparing with each other. This, to me, seems to be the
> >purpose of an enumerated type.
>
> Have you tried yet to use two different enum instances as keys in
> the same dict?

What do you mean by "enum instances"? I presume you mean "values from
a single enum".

    >>> colour_german = { colours.red: "rot", colours.green: "grün",
    >>> colours.blue: "blau" }
    >>> for val in colours:
    ...     print colour_german[val]
    ...
    rot
    blau
    grün

> Then try to sort the keys(or items is the values are misc different
> enums).

Oh, perhaps you mean "enum values from different enum instances". No,
those won't compare against each other; there's no meaningful
relationship, since different enum instances are conceptually
different types.

> I hit that, and changed __cmp__ to compare (typename, <intvalue or
> other if not int subtype>) tuples.

I think this is a flaw, based on expecting too strong a relationship
between the enum value instance, and an integer value.

> That sorts items grouped by enum type if they're keys.

Why should colours.blue compare before fruits.orange? How is that
meaningful?

> >I think I've addressed all your current concerns; I don't believe
> >an inherent correlation to integers is necessary at all.
> 
> Necessary wasn't the question for me. It's whether it's desirable.
> YMMV ;-)

I'm still trying to understand what is served by having some exposed
relationship between an enum value instance and an integer value.

> >It's no more necessary than saying that ["a", "b", "c"] requires
> >that there be some specific correlation between the values of that
> >list and the integers 0, 1, 2. If you *want* such a correlation, in
> >some particular case, use enumerate() to get it; but there's
> >nothing about the values themselves that requires that
> >correspondence.
>
> Yet it is comforting to know that ['a', 'b', 'c'][0] will interpret
> the [0] to mean the first in the sequence (unless someone is doing a
> list-like repr trick based on some other type ;-).

Again, you're only talking about *sequence*, not correspondence to
integers. Your case above isn't an argument in favour of "the 'a'
value should coerce to the 0 value". Why then should an enum value
instance coerce to any particular integer value?

> The class methods are introduced via metaclass in the makeEnum factory
> and it's a very hacky workaround for the fact that execution of a
> class definition body only has local and module global namespace, so
> you can't directly reference anything local to the factory function.

Here you've lost me, since I don't understand why you want
enumerations to be classes at all. Are you going to be making
instances of an entire enumeration? If not, why make classes instead
of objects?

-- 
 \     "The illiterate of the future will not be the person who cannot |
  `\     read. It will be the person who does not know how to learn."  |
_o__)                                                 -- Alvin Toffler |
Ben Finney