Python's sad, unimaginative Enum

[Mark Lawrence]

That's the title of this little beast
http://www.acooke.org/cute/Pythonssad0.html if anybody's interested.

 

[Steven D'Aprano]

That's the title of this little beast
http://www.acooke.org/cute/Pythonssad0.html if anybody's interested.

Well, that's one way of looking at it. And I can't exactly *disagree*.

But... but...

In many ways, it's a dull language, borrowing solid old concepts
from many other languages & styles: boring syntax, unsurprising
semantics, few automatic coercions, etc etc. But that's one of
the things I like about it. -- Tim Peters, 16 Sep 93


Being "sad and unimaginative" is a *good thing* when it comes to syntax.
Which would you rather read?

Python:

try:
int(astring)
except ValueError:
print(False)



APL:

⊃⎕VFI{wâ†âµâ‹„((w='-')/w)â†'¯'â‹„w}


[pedant: okay, so the two code snippets are not *exactly* equivalent. So
sue me.]


Let's look at his major criticisms:

1) values aren't automatically generated.

True. So what? That is the *least* important part of enums. The most
important things about enums are:

- they aren't strings, but look like symbolic values;

- or they are ints (for compatibility with C libraries) that look like
symbolic values.

Probably half the use-cases for enums are for compatibility with C
libraries, where you *need* to specify the value. There's no point you
defining an enum SOCK_RAW, having Python decide to set it to 7, when the
rest of the world agrees it should have the value 3.


2) The enum implementation allows duplicates.

Yes, this *is* a feature. In the real world, enums are not unique. There
are aliases (maybe you want FAMILY_NAME and SURNAME to be the same enum),
and misspelled enums need to be corrected:


class Insects(Enum):
bee = 2
ant = 3
wasp = 4 # Preferred spelling.
wsap = 4 # Oops, keep this for backward compatibility!


I'm sorry for all those who can't avoid duplicating values, but really,
Python doesn't protect them from other silly typos, why are Enums so
special that they need to be treated differently?


3) the functional API for creating auto-numbered Enums "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).
[end quote]


Then maybe you shouldn't be relying on such a lousy IDE then.

Well, perhaps I'm being a tad harsh. After all, it's not like it is a
*feature* that namedtuple *requires* you to include the class name. But
really, it's a trivial inconvenience. Python has much worse, e.g.:

- why aren't my CONSTANTS actually constant?


and yet somehow we survive.


4) Auto-generated enums aren't strings:

That would makes sense (red = 'red'), in that it would display
nicely and is going to provide easy to debug values. So nope.
[end quote]

Missing the point entirely. The *whole point* of enum red is that it WILL
display as 'red', even though it wraps an underlying value of <whatever
arbitrary value Python generates>. So this is a non-issue.



I think Enums will be good addition to the standard library, and I look
forward to dropping support for Python 3.3 so I can rely on them

 

[Chris Angelico]

Let's look at his major criticisms:

1) values aren't automatically generated.

True. So what? That is the *least* important part of enums.

I stopped following the -ideas threads about enums, but IIRC
autogeneration of values was in quite a few of the specs early on. So
you can probably find the arguments against it in the list archives.

FWIW, though, I do like C's autogeneration of enum values - but use it
in only a small proportion of my enums. It's not a terrible loss, but
it is a loss.

ChrisA

 

[88888 Dihedral]

Chris Angelicoæ–¼ 2013å¹´5月14日星期二UTC+8上åˆ1時36分34秒寫é“：

I stopped following the -ideas threads about enums, but IIRC

autogeneration of values was in quite a few of the specs early on. So

you can probably find the arguments against it in the list archives.



FWIW, though, I do like C's autogeneration of enum values - but use it

in only a small proportion of my enums. It's not a terrible loss, but

it is a loss.



ChrisA

Because a hash table can replace the enums in other languages,
it is more pythonic to use a dictionary built first
to replace the enums.

I think it is the same style of programming in perl and ruby.