Bengt Richter <[EMAIL PROTECTED]> wrote: > On Sat, 19 Nov 2005 11:10:42 +1100 (EST), Ben Finney <[EMAIL PROTECTED]> > wrote: > >Bengt Richter <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list