Python's sad, unimaginative Enum

[Steven D'Aprano]

On Mon, 13 May 2013 10:24:40 +0100, Mark Lawrence wrote:

> 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:

[quote]
  - 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:

[quote]
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 :-)


-- 
Steven