Steven Bethard <[EMAIL PROTECTED]> writes: > Ben Finney wrote: >> This PEP specifies an enumeration data type for Python. >> An enumeration is an exclusive set of symbolic names bound to >> arbitrary unique values. Values within an enumeration can be iterated >> and compared, but the values have no inherent relationship to values >> outside the enumeration. > > -1 on the proposal as-is. I don't have many use cases for > enumerations, and I don't think they merit appearing in the builtins. > If you put them in the collections module instead, I'd probably be +0.
This seems to be a common distinction. Should I amend the PEP to propose "either in the builtins or in the collections module"? Or should I propose two PEPs and let them compete? >> This allows the operation to succeed, evaluating to a boolean value:: >> >>> gym_night = Weekdays.wed >> >>> gym_night < Weekdays.mon >> False >> >>> gym_night < Weekdays.wed >> False >> >>> gym_night < Weekdays.fri >> True >> >>> gym_night < 23 >> False >> >>> gym_night > 23 >> True >> >>> gym_night > "wed" >> True >> >>> gym_night > Grades.B >> True > > For the few cases of enumerations that I've needed, I've never > wanted them to be comparable with <, >, etc. If there were two > classes, say ``collections.Enum`` and ``collections.OrderedEnum`` > where only the latter made the enumerated items comparable, you > might even get me as high as +0.5. (I only care about the > non-comparable one, but I understand that others may have a need for > the comparable one.) Replies to your post indicate this is another popular distinction. But the terminology is broken. The term "enumerated" seems to me to imply that it does have an order. Can you suggest a term other than "enumerated" for what you're describing with the unordered property? -- \ "For every complex problem, there is a solution that is simple, | `\ neat, and wrong." -- Henry L. Mencken | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
