Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #45233 > unrolled thread

Python's sad, unimaginative Enum

Back to article view | Back to comp.lang.python

Contents

  Python's sad, unimaginative Enum Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-05-13 10:24 +0100
    Re: Python's sad, unimaginative Enum Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-13 10:17 +0000
      Re: Python's sad, unimaginative Enum Chris Angelico <rosuav@gmail.com> - 2013-05-14 03:36 +1000
        Re: Python's sad, unimaginative Enum 88888 Dihedral <dihedral88888@googlemail.com> - 2013-05-14 18:21 -0700

#45233 — Python's sad, unimaginative Enum

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

-- 
If you're using GoogleCrap™ please read this 
http://wiki.python.org/moin/GoogleGroupsPython.

Mark Lawrence

[toc] | [next] | [standalone]

#45235

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

[toc] | [prev] | [next] | [standalone]

#45253

On Mon, May 13, 2013 at 8:17 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#45318

Chris Angelico於 2013年5月14日星期二UTC+8上午1時36分34秒寫道：
> On Mon, May 13, 2013 at 8:17 PM, Steven D'Aprano
> 
> <steve+comp.lang.python@pearwood.info> wrote:
> 
> > 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

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web