On Tue, Jan 29, 2013 at 6:45 PM, Eli Bendersky <eliben@gmail.com> wrote:
On Tue, Jan 29, 2013 at 3:26 PM, Greg Ewing <greg.ewing@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)