"Giovanni Bajo" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
