PEP 354: Enumerations in Python

[Ben Finney]

"Giovanni Bajo" <noway at sorry.com> writes:
> Kay Schluehr wrote:
>> Ben Finney wrote:
>>> One motivation for having a class (rather than an instance) for
>>> each enumeration is to allow subclasses of enumerations, extending
>>> and altering an existing enumeration.  A class, though, implies
>>> that instances of that class will be created; it is difficult to
>>> imagine what it means to have separate instances of a "days of the
>>> week" class, where each instance contains all days.  This usually
>>> leads to having each class follow the Singleton pattern, further
>>> complicating the design.
>>
>> Maybe a metaclass implementation complicates design, but usage is
>> quite simple and flexible. The classics is already referenced by
>> the Python docs:
>>
>> http://www.python.org/doc/essays/metaclasses/Enum.py
>
> Agreed. Allowing subclassing of an existing enum is a strong plus to me.

Having classes as enumerations seems to me to complicate the
conceptual model. As I see it, an enumeration is a container
object. For a container object to be subclassed has no obvious
semantic meaning.

If an enumeration object were to be derived from, I would think it
just as likely to want to have *fewer* values in the derived
enumeration. Subclassing would not appear to offer a simple way to do
that.

To preserve the promise that every enumeration's values are unique,
even the values that were inherited would need to be different in each
enumeration. This, again, doesn't fit well with the concept of
subclassing.

I can see value in wanting to derive a new enumeration from an
existing one; I just don't think subclassing makes sense for that
operation.

How would you specify the interface for deriving one enumeration from
another?

-- 
 \        "Good judgement comes from experience. Experience comes from |
  `\                           bad judgement."  -- Frederick P. Brooks |
_o__)                                                                  |
Ben Finney