[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Stephen J. Turnbull]

Antoine Pitrou writes:
 > On Tue, 26 Feb 2013 08:03:40 -0800
 > Ethan Furman <ethan at stoneleaf.us> wrote:
 > > I'm beginning to see why enums as a class has not yet been added
 > > to Python.  We don't want to complicate the language with too
 > > many choices, yet there is no One Obvious Enum to fit the wide
 > > variety of use-cases:
 > > 
 > >    - named int enums  (http status codes)
 > >    - named str enums  (tkinter options)
 > >    - named bitmask enums  (file-type options)
 > >    - named valueless enums  (any random set of names)
 > >    - named valueless-yet-orderable enums  (any not-so-random set of names ;)

I don't see what the problem is with having a very restricted base
Enum class and providing a number of convenience subclasses.

 > I don't think valueless enums have a point. Just make them str enums.

I suppose Ethan doesn't mean "no value at all", he means "no operations
available on the value" (ie, you need to explicitly convert from the
enumerator to an int or str to add or compare them).  str enums won't
satisfy that requirement.  They are implicitly orderable and addable.
Furthermore, the str order is probably quite wrong.  If the enum is
orderable, I would expect declaration order.

As far as I can see, what you (Antoine) want is an identifier with a
constant value, no more and no less.  Grouping into an enum is merely
a lexical convention, since you are happy to compare enums of
different enum classes and enums with ints.

I think such a thing is pretty generally desirable, but most of the
people who have created Enum classes implement some type-checking that
this value came from that Enum.  To me that is what differentiates an
enumerated constant from a generic named constant.  I don't see why
you keep deprecating that feature.  Do you really think it's useless,
or is it just that you wouldn't use it yourself?