Mark Summerfield wrote:
On 2008-01-23, Tal Einat wrote:
-1 on adding a specific construct for enums.
What I usually do in Python is this:
ERROR, OK, ALSO_OK = range(-1, -1 + 3)
Start and stop values, as well step sizes other than one, are easily achieved. Skipping values is done like this:
ERROR, OK, ALSO_OK, SOMEOTHER, LAST = range(-1, -1 + 3) + range(1000, 1000 + 2)
Updating the range(s) appropriately when adding/changing values is easy enough. I find this solution to be good enough since the values are not ever meant to be used explicitly, and values are not added/changed often.
This is perhaps not very pretty or concise, but it's simple and it only uses Python syntax and constructs which everyone knows and understands. Readability and simplicity are usually my top concerns, so this fits the bill.
Unfortunately, the "const-ness" of enums defined this way is merely conventional, so it is easy to change the value of one by mistake.
Using namedtuples means that if you try to assign to the thing you at least get an exception raised. Not that I'm particularly in favour of using namedtuples for this purpose, but they are the only "convenient" way to have enums based on the standard library that I know of.
(You mean that namedtuples are the only "convenient" way to have _"const"_ enums, right?) Well, not many things in Python are "const" at all. I didn't realize this ("const-ness") was a criterion. So, just to be clear, you want a construct which allows setting sequential numerical values to names (variables or otherwise), which become "const" from that point onwards. Is this correct? If that's the case, then I'm still -1. The reason is that, IMHO and AFAIK, having "const" things is un-Pythonic. I think it -great- that I can override anything in Python, even if the original author of the code didn't imagine a reason one would want to do so. - Tal