<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#330033" bgcolor="#ffffff">
On 11/23/2010 11:34 AM, Guido van Rossum wrote:<br>
<blockquote
cite="mid:AANLkTinv_U39BE_QzF9DwfLrBvkR5-BqGO2KexhL+-F3@mail.gmail.com"
type="cite">
<pre wrap="">The best example of the utility of enums even for Python is bool. I
resisted this for the longest time but people kept asking for it. Some
properties of bool:
(a) bool is a (final) subclass of int, and an int is acceptable in a
pinch where a bool is expected
(b) bool values are guaranteed unique -- there is only one instance
with value True, and only one with value False
(c) bool values have a str() and repr() that shows their name instead
of their value (but not their class -- that's rarely an issue, and
makes the output more compact)
I think it makes sense to add a way to the stdlib to add other types
like bool. I think (c) is probably the most important feature,
followed by (a) -- except the *final* part: I want to subclass enums.
(b) is probably easy to do but I don't think it matters that much in
practice.
</pre>
</blockquote>
<br>
I was concerned about uniqueness constraints some were touting.
While that can be a useful property for some enumerations, it can
also be convenient for other enumerations to have multiple names map
to the same value.<br>
<br>
Bool seems appropriately not extensible to additional values. While
there are tri-valued (and other) logic systems, they deserve a
separate namespace.<br>
<br>
Bool seems to be an example, then of a "set of distingushed names,
with values associated to the names", and is restricted to [two]
[unique] integer values. C/C++/C# enum is somewhat like that, and
is also restricted to integer values [not necessarily unique]. I
wonder if a set of distinguished names need to be restricted to
integer values to be useful, although I have no doubt that
distinguished names with integer values are useful. Someone used an
example of color names class having RGB tuple values, which is a
counter example to a restriction to integers. I can think of others
as well.<br>
<br>
Perhaps a "set of distinguished names, with values associated to the
names" is really a dict, with the unique names restricted to Python
identifier syntax (to be useful), and the values unrestricted. The
type of the named value, and the value of the named value, seem not
to need to be restricted.<br>
<br>
But the implementations<br>
<br>
Bool = dict('False': 0, 'True': 1)<br>
<br>
or alternately<br>
<br>
class Bool():<br>
self.False = 0<br>
self.True = 1<br>
<br>
is missing a couple characteristics of Python's present bool: the
names are not special, and the values are not immutable. Perhaps
games could be played to make the second implementation effectively
immutable.<br>
<br>
So I think the real trick of the "enum" (or a generalized
"distinguished names") is in the naming. A technique to import the
keys that are legal Python identifiers from a dict into a namespace,
and retain henceforth immutable values for those names would permit
the syntactical usage that people are accustomed to from the
C/C++/C# enum, but with extended ranges and types of values, and it
seems Bool could be mostly reimplemented via that technique.<br>
<br>
What is still missing? The "debugging" help: the values, once
imported, should not become "just" values of their type, but rather
a new type of value, that has an associated name (and type, I
think). Whatever magic is worked under the covers to make sure that
there is just one True and just one False, so that they can be
distinguished from the values 1 and 0, and so reported, should also
be applied to these values.<br>
<br>
So there need not be new syntax for creating the name/value pairs;
just use dict. The only new API would be the code that "imports"
the dict into the local namespace.<br>
<br>
Note that other scoped definitions of True and False are not
possible today because True and False are keywords. It would be
inappropriate to define these distinguished names as all being
keywords, so it seems like one could still override the names, even
once defined, but such overridden names would lose their special
value that makes them a distinguished name.<br>
</body>
</html>