[Python-Dev] constant/enum type in stdlib

[Glenn Linderman]

On 11/23/2010 11:34 AM, Guido van Rossum wrote:
> 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.

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.

Bool seems appropriately not extensible to additional values.  While 
there are tri-valued (and other) logic systems, they deserve a separate 
namespace.

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.

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.

But the implementations

Bool = dict('False': 0, 'True': 1)

or alternately

class Bool():
     self.False = 0
     self.True = 1

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.

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20101123/910262da/attachment.html>