[Python-ideas] constant/enum type in stdlib

[Guido van Rossum]

On Tue, Jan 29, 2013 at 6:45 PM, Eli Bendersky <eliben at gmail.com> wrote:
> On Tue, Jan 29, 2013 at 3:26 PM, Greg Ewing <greg.ewing at canterbury.ac.nz>
> wrote:
>>
>> Eli Bendersky wrote:
>>>
>>> I really wish there would be an enum type in Python that would make
>>> sense. ISTM this has been raised numerous times, but not one submitted a
>>> good-enough proposal.
>>
>> I think the reason the discussion petered out last time
>> is that everyone has a slightly different idea on what
>> an enum type should be like. A number of proposals were
>> made, but none of them stood out as being the obviously
>> right one to put in the std lib.
>>
>> Also, so far nobody has come up with a really elegant
>> solution to the DRY problem that inevitably arises in
>> connection with enums. Ideally you want to be able to
>> specify the names of the enums as identifiers, and not
>> have to write them again as strings or otherwise provide
>> explicit values for them. That seems to be very difficult
>> to achieve cleanly with Python syntax as it stands.

Hm, if people really want to write something like

color = enum(RED, WHITE, BLUE)

that might still be true, but given that it's likely going to look a
little more like a class definition, this doesn't look so bad, and
certainly doesn't violate DRY (though it's somewhat verbose):

class color(enum):
  RED = value()
  WHITE = value()
  BLUE = value()

The Python 3 metaclass can observe the order in which the values are
defined easily by setting the class dict to an OrderdDict.

> Since we're discussing a new language feature, why do we have to be
> restricted by the existing Python syntax? We have plenty of time before 3.4
> at this point.

Introducing new syntax requires orders of magnitude more convincing
than a new library module or even a new builtin.

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