Comments:"Andrew Cooke: C[omp]ute"
URL:http://www.acooke.org/cute/Pythonssad0.html
Python's sad, unimaginative Enum
From: andrew cooke <andrew@...>
Date: Sat, 11 May 2013 11:03:33 -0400
Python is about to get an Enum. See http://www.python.org/dev/peps/pep-0435/ And it's sad. It's not awful. It just fails to do anything particularly well - it's an awkward compromise whose only real achievement is not doing anything new. What would you expect a Pythonic enum to look like? class Colour(Enum): red green> print(Colour.red == Colour.green) false That's about the minimum, right? But it doesn't do that. The above would require new syntax, so instead you have to define values: class Colour(Enum): red = 1 green = 1 Still, at least the mistake above would raise an error. Wouldn't it? Nope. That's a feature. If you mess up on the non-optional values then you get "aliases". Because that's something I've waited all my life for, while I never make mistakes... Or something. The something being that they are smoking fucking crack. But you could just as well type: class Colour: red = 1 green = 2 so what does Enum get you? It provides a bit of metaclass goop to let you iterate over values, etc. Whoop. So, you go hunting around in the docs to see if there's any way at all of avoiding the need to assign values manually. And there is: Colour = Enum('Colour', 'red, green') which suffers from the same problems as namedtuples: - you need to repeat the class name (in a string, which your IDE is unlikely to check) - the parameters are themselves in a string, which your IDE is unlikely to parse and provide in auto-complete (they can be separate strings, in a sequence, but that doesn't really help). Now if two potentially useful library classes are suffering from the same problems than isn't that a BIT OF A HINT to try make things better? Nope. It just shows how important it is to not be imaginative. Or something (crack). And it gets worse. What values do you think the above provides? Strings? That would makes sense (red = 'red'), in that it would display nicely and is going to provide easy to debug values. So nope. Integers from zero? I mean that's how Python counts indices and there's "only one way to do it" so that's how Python counts enums, right? Nope. OK, so bit fields? That way we can do cool Colour.red | Colour.green and make the C programmers feel at home? Nope. Give up? I'll tell you. It counts from 1. Presumably because it's really common to use the "if not enum" idiom. In someone's crack-addled dreams. Like I said at the start. None of this is really awful. It's just lame. It's design by committee that finds the least offensive, least imaginative, least useful solution. One big pile of meh. Andrew
Enum
From: Peter Norvig <pnorvig@...>
Date: Sat, 11 May 2013 11:37:40 -0700
If you don't like writing "red = 1; green = 2" etc you can just do
Colour = Enum('Colour', 'red green blue ...')Re: Enum
From: andrew cooke <andrew@...>
Date: Sat, 11 May 2013 15:12:27 -0400
I can't believe who I am saying this to... but dude, read the article before you comment. Andrew
What would be imaginative?
From: andrew cooke <andrew@...>
Date: Sat, 11 May 2013 15:33:53 -0400
Maybe Python needs to start considering something like atoms? That would address the need to hde names in strings and might also provide a more suitable value type for enums. Is there some (new?) syntax that could give a named scope, to avoid the need to repeat class names? It seems like there are underlying language issues that need a more imaginative solution... Andrew