PEP 285: Adding a bool type

[John Roth]

"Guido van Rossum" <guido at python.org> wrote in message
news:3CB1CA65.ECE0437C at python.org...
> John Roth wrote:
> > Unfortunately, I don't see a PEP on enums. Maybe I should
> > dust off the rewrite of the set PEP I made that included them.
>
> You could reuse some of the implementation techniques I used
> for bool.  Then bool could later be retrofitted as an enum.
> Like bool, I expect that the key benefit of enums is that
> when you print them you'll get their name instead of their
> value.  Currently I use string literals for that, but it's
> not always optimal, and doesn't work for C APIs.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)

I'm not certain that's a real good idea (the make bools
an enum part.) The reason is that, conceptually, bools
are an answer to the question: is it or isn't it? Enums
are an enumeration of cases. An instance of an enum
is a specific case from the list; a set based on an enum
is the union of all cases that are present.

We have (hopefully) finished bashing that question into
a pulp; I simply don't see modeling either concept on the
integers as promoting anything but confusion. I'm reasonably
happy with the compromises that had to be made with the
bool implementation - after all, I come from an IBM
mainframe background, and compatibility uber alles!
However, since I don't see the need to retrofit enums
into anything existing, I don't see why we would need
the same level of compatibility hack. I certainly don't
see the need of another upheaval by changing bool a
second time.

This isn't to say that mapping enums and integers can't
be useful, and I intend to carry on with Pascal's ideas
in that direction. I see performing arithmetic on enums
to be a useful subset of enums in general: when you need
it, you need it, but otherwise it's simply useless. For
example, an enum of days of the week can usefully
be set up for arithmetic, but an enum of error codes
probably would have no need for that. However,
a mapping would be useful in both cases for sequence
indexes, and also for the standard representation of
sets as bit strings.

In fact, I intend to extend them a bit
by allowing the enum definition to specify whether the
integer sequence is open or closed (that is, whether
addition off the end causes an exception, or whether
it wraps.)

Also, I'm not certain there are a large number of places
in Python where an enum is appropriate as a return
value. In most of those cases, the appropriate return
technique would be to return an instance of a class,
not an enum. For example, the change to the exception
mechanism that replaced string exceptions with instances
of exception objects. Although string exceptions are
still valid, I don't see anything to be gained by replacing
them with enums.

As a final note, how do I submit an acceptable PEP?
That is, what are the restrictions on formatting it? If I
have to format it myself like the rest of the PEPs and
documentation, it's going to be a while.

John Roth