PEP 354: Enumerations in Python
bignose+hates-spam at benfinney.id.au
Wed Mar 1 02:26:19 CET 2006
Steven Bethard <steven.bethard at gmail.com> 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
>> This allows the operation to succeed, evaluating to a boolean value::
>> >>> gym_night = Weekdays.wed
>> >>> gym_night < Weekdays.mon
>> >>> gym_night < Weekdays.wed
>> >>> gym_night < Weekdays.fri
>> >>> gym_night < 23
>> >>> gym_night > 23
>> >>> gym_night > "wed"
>> >>> gym_night > Grades.B
> 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 |
More information about the Python-list