[Python-Dev] constant/enum type in stdlib

[Guido van Rossum]

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.AF_INET,
>> 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 = <enumclass>(i). It would be nice if s = str(e) and
e = <enumclass>(s) would work too.

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