[Python-Dev] constant/enum type in stdlib (original) (raw)

Guido van Rossum guido at python.org
Tue Nov 23 20:34:17 CET 2010

On Tue, Nov 23, 2010 at 10:06 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

Le mardi 23 novembre 2010 à 12:57 -0500, Fred Drake a écrit :

On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou <solipsis at pitrou.net> wrote: > Enumerations aren't a type at all (they have no distinguishing > property).

In any given language, this may be true, or not.  Whether they should be distinct in Python is core to the current discussion. I meant "type" in the structural sense (hence the parenthesis). enums are just auto-generated constants. Since Python makes it trivial to generate sequential integers, there's no need for a specific "enum" construct. Now you may argue that enums should be strongly-typed, but that would be a bit backwards given Python's preference for duck-typing.

Please take a step back.

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.

From a backward-compatibility perspective, what makes sense depends on whether they're used to implement existing constants (socket.AFINET, etc.) or if they reserved for new features only. It's not only backwards compatibility. New features relying on C APIs have to be able to map constants to the integers used in the C library. It would be much better if this were done naturally rather than through explicit conversion maps.

I'm not sure what you mean here. Can you give an example of what you mean? I agree that it should be possible to make pretty much any constant in the OS modules enums -- even if the values vary across platforms.

(this really means subclassing int, if we don't want to complicate C-level code)

Right.

FWIW I don't think I'm particular about the exact API to construct a new enum type in Python code; I think in most cases explicitly assigning values is fine. Often the values are constrained by something external anyway; it should be easy to dynamically set the values of a particular enum type (even add new values after the fact). There might also be enums with the same value (even though the mapping from int to enum will then have to pick one).

I expect that the API to convert between enums and bare ints should be i = int(e) and e = (i). It would be nice if s = str(e) and e = (s) would work too.

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list