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

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

Re: Enum questions.

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Enum questions. Grant Edwards <grant.b.edwards@gmail.com> - 2016-04-13 13:50 +0000
    Re: Enum questions. Marko Rauhamaa <marko@pacujo.net> - 2016-04-13 17:07 +0300
      Re: Enum questions. Ethan Furman <ethan@stoneleaf.us> - 2016-04-13 07:21 -0700
      Re: Enum questions. Ethan Furman <ethan@stoneleaf.us> - 2016-04-13 14:13 -0700

#106941 — Re: Enum questions.

On 2016-04-13, Michael Selik <michael.selik@gmail.com> wrote:
> On Wed, Apr 13, 2016, 12:14 PM Antoon Pardon <antoon.pardon@rece.vub.ac.be> wrote:
>
>> I have been looking at the enum documentation and it seems enums
>> are missing two features I rather find important.
>>
>> 1) Given an Enum value, someway to get the next/previous
>>    one
>>
>> 2) Given two Enum values, iterate over the values between
>>    them.
>>
>> Did I miss those in the documentation or are they really missing?
>
> An Enum corresponds to "nominal" data that is coded as a number
> simply for storage rather than meaning.

FWIW, as an old Pascal programmer, I too would have been surprised
that an "enum" is not ordinal and doesn't support a next/prev and
iteration.

As an old C programmer, not so much. :)

-- 
Grant Edwards               grant.b.edwards        Yow! Today, THREE WINOS
                                  at               from DETROIT sold me a
                              gmail.com            framed photo of TAB HUNTER
                                                   before his MAKEOVER!

[toc] | [next] | [standalone]

#106943

Grant Edwards <grant.b.edwards@gmail.com>:

> On 2016-04-13, Michael Selik <michael.selik@gmail.com> wrote:
>> An Enum corresponds to "nominal" data that is coded as a number
>> simply for storage rather than meaning.
>
> FWIW, as an old Pascal programmer, I too would have been surprised
> that an "enum" is not ordinal and doesn't support a next/prev and
> iteration.
>
> As an old C programmer, not so much. :)

From the Pascal point of view, the "number for storage" seems odd. Why
not:

    class Color(enum.Enum):
        red = "red"
        blue = "blue"
        green = "green"

or:

    class Color(enum.Enum):
        red = object()
        blue = object()
        green = object()

or:

    class Color(enum.Enum):
        red
        blue
        green


This last one is to the point but raises a NameError.


Personally, I have not found enum.Enum all that appealing. If I have
needed such enums in my code, I have usually just defined:

    class MyClass:
        RED = "RED"
        BLUE = "BLUE"
        GREEN = "GREEN"
            

Marko

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

#106945

On 04/13/2016 07:07 AM, Marko Rauhamaa wrote:

>      class Color(enum.Enum):
>          red
>          blue
>          green
>
>
> This last one is to the point but raises a NameError.

Using the aenum library that last one is possible.  It also has 
NamedConstant and a metaclass-derived NamedTuple! </shameless plug>

--
~Ethan~

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

#106965

On 04/13/2016 07:21 AM, Ethan Furman wrote:
> On 04/13/2016 07:07 AM, Marko Rauhamaa wrote:
>
>>      class Color(enum.Enum):
>>          red
>>          blue
>>          green
>>
>>
>> This last one is to the point but raises a NameError.
>
> Using the aenum library that last one is possible.  It also has
> NamedConstant and a metaclass-derived NamedTuple! </shameless plug>

Oh, and to keep it mostly safe, the magic that creates the missing names 
is turned off as soon as something real happens, like creating a 
property or a method.

--
~Ethan~

[toc] | [prev] | [standalone]

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

csiph-web