[Python-ideas] adopt an enum type for the standard library?
taleinat at gmail.com
Wed Jan 23 20:14:54 CET 2008
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.
More information about the Python-ideas