PEP 354: Enumerations in Python

[Terry Hancock]

On Wed, 01 Mar 2006 12:26:19 +1100
Ben Finney <bignose+hates-spam at benfinney.id.au> wrote:
> Steven Bethard <steven.bethard at gmail.com> writes:
> > -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?

My recommendation is to drop the "builtins" suggestion
altogether. If it goes into the stdlib and becomes popular,
write a PEP suggesting it move to builtins *then*. That
would follow the example of "sets".

I for one think that builtins is already too large (though
I admit I'm unsure what should be removed).  Enumerations
are used infrequently enough that they should be a module
(e.g. "decimal" numbers are probably more common).

> > 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?

Well, I personally don't find the term that broken, but as
I say, the term "Vocabulary" has been used. There is "Open
Vocabulary" and "Closed Vocabulary" to define the mutable
and immutable cases respectively. But they're long names.

Plus, you need a name for the individual values. So there
are a number of possibilities:

EnumValue / Enum
Symbol / SymbolSet
Word / Vocabulary
Symbol / Vocabulary (what I used for "open" case)
Symbol / Enum       (what I used for "closed" case)
Word / WordSet
Label / LabelSet

I'm sure there are others.

Word has the disadvantage of also meaning "32-bit integer"
to a lot of CS people.  Or perhaps a string.  Not
immediately an indivisible symbol.

Symbol probably has a dozen overloaded meanings, though
I'm not sure what other people will think when they read it
(it actually seems right to me, obviously).

Label was what I first called these. But I realize that
label describes a probably use of a symbol, not the symbol
itself.



-- 
Terry Hancock (hancock at AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com