PEP 354: Enumerations in Python

[Terry Hancock]

On Tue, 28 Feb 2006 14:26:49 -0500
"Terry Reedy" <tjreedy at udel.edu> wrote:
> "Stefan Rank" <stefan.rank at ofai.at> wrote in message 
> news:440415A1.7070503 at ofai.at...
> > recent examples from this list:
> >
> > 2006-01-03:
> > http://www.nabble.com/Re%3A-Regex-anomaly-p2179421.html
> > 2006-02-20:
> > http://www.nabble.com/Re%3A-Regular-expression-gone-mad-p3029028.html
> 
> If the re flags were implemented as instances of object
> instead of int, then misuse of them as int args would be
> excepted.  I don't know if such a  change would otherwise
> cause a problem.
> 
> I wonder whether a subclass of object (EnumSet?) that
> allowed for  initialization with a better string
> representation and that disabled order  comparisons would
> fill the bill for unordered enum.
> 
> As Steven Bethard also noted, there seem to be a need for
> two Enum  subclasses:
> EnumSet and EnumSeq.

And one other distinction -- mutable versus immutable. A
immutable enum is the usual use case, a mutable one is a
"vocabulary" (i.e. an open set of symbols, which
nevertheless requires controlled access).

The key thing about symbols like enums etc is that they
don't really represent anything (or that which they
represent is inconvenient to bind to the symbols -- perhaps
its even an abstract concept that has no programmatic
representation beyond the enumerated value).

One thing about an enumerated value is that it should know
what enum it belongs to. For example, I'm currently working
on a project that has the following rather unfortunate
near-collision of symbols:

sym.ABSTRACTS  "scope of abstract nouns" in 
                   SCOPE vocabulary

sym.ABSTR      "definiteness of abstract noun" in 
                   ARTICLE enum

sym.ABST       "number of noun which has no
                   count because abstract (not mass)"
                   NUMBER enum

It's quite useful that I can ask "sym.ABST" which one of
the above domains it's in:

>>> sym.ABST.domain
NUMBER

or even better:

>>> sym.ABST
<!NUMBER: ABST>

Which makes the enumeration values somewhat
self-documenting.  I'm currently trying to figure out how
best to make this instead show (e.g.):

>>> sym.ABST
<!NUMBER: ABST - Noun uncountable because abstract.>

I can of course, also use this to catch errors by checking
that the pluralization function in my locale module has
been passed a NUMBER or an explicit int, instead of say, a
SCOPE, by accident.

Another feature here is that all of these symbols, though
also defined within their domain collections is also made
into an attribute of the sym object (which is a "trivial
class" or "convenience namespace").

I also raise an error if any domain tries to overwrite a
symbol in sym, so I can avoid accidental collisions.

I'm still tinkering with this, and the above is from memory,
but I do have it working on another machine. I'm currently
subclassing from dict, not set, though I'm unsure if this is
really wise (but I'm more familiar with dict, and I'm
currently making use of the mapping internally, though I'm
not sure I really need to).

I'm not sure this would be a smart way to do this in another
application, but it looks promising for this one (which is
a kind of artificial locale-neutral language
representation).

I'm not sure that the enum described in the PEP would be as
useful to me as this.  So  I'm -0 on it becoming a built-in,
though I'm +0 on it becoming a module (it's not that hard
to type "from enum import Enum").  But I'm not sure it's the
"best" enum, or even that "one size fits all" with enums
(though having fewer implementations might improve clarity
if they are really equivalent).

Cheers,
Terry

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