[Python-ideas] PEP XXX - Competitor with PEP 435: Adding an enum type to the Python standard library

[Alex Stewart]

Sigh..

I apologize for coming back in a bit late and still not really up to speed,
but various real-world things ended up sidetracking me and over the past
week or two and I haven't been able to spend as much time here as I'd like
to..

I haven't yet had a chance to read the proposed PEP, but based on the
discussions I'm seeing, I have to admit I'm a little disappointed that I
thought we had already managed to come together with a pretty common list
of properties that we all agreed on for enum-like things in Python, and I
had started putting together a sample implementation based on those
principles (which I never really heard anybody say anything substantially
bad about, so I assumed it was sorta on the right track) and now it sounds
like we're going off in significantly different directions again, and I'm
not sure why.  If this is in fact the case, it seems to me that crafting
yet another PEP which doesn't mesh with half the community's expectations
is not really useful and is probably premature, and we should probably go
back to talking more about conceptually what we're actually trying to
accomplish here first.

FYI, I have actually been working on a newer version of my enum
implementation which includes support for compound enums (i.e. "oring" enum
values together), and I believe covers almost all of the properties that
I've heard people express a desire for on this list, and avoids most of the
things people seem to have major issues with, so I would be interested to
know if people actually have problems with it.  I'll see if I can get it
cleaned up a bit and up on github in the next day or two so folks at least
have an idea of how I've been looking at this stuff and can comment on what
they think..

Regarding the issue of bitmask-enums, I do agree that they are common
enough in various APIs that it is important that we be able to support them
easily.  *However,* I have yet to see how or why they are actually
different than int-enums in any practical way.  I don't see why we need to
treat them as a different category at all and I see no value in doing so.
 They're all just* *int-enums.  Problem solved.

(I might have some thoughts on some of the rest of this stuff too, but I
want to try to find a bit of time and read up on the new proposed-PEP and
discussions before I respond further..)

--Alex

On Tue, Mar 12, 2013 at 1:40 PM, Ethan Furman <ethan at stoneleaf.us> wrote:

> On 03/12/2013 01:07 PM, Andrew Barnert wrote:
>
>> From: Eli Bendersky <eliben at gmail.com>
>> Sent: Tuesday, March 12, 2013 10:28 AM
>>
>>
>>  On Tue, Mar 12, 2013 at 9:59 AM, Andrew Barnert <abarnert at yahoo.com>
>>> wrote:
>>>
>>> On Mar 12, 2013, at 8:36, Eli Bendersky <eliben at gmail.com> wrote:
>>>
>>>>
>>>>  It is actually better, because it emphasizes that NamedInt is just
>>>>> that, not a kind of Enum. There's just one enum. Moreover, I'm not sure why
>>>>> strings need to be named (they name themselves just fine). And moreover+,
>>>>> Bitmask IMHO is completely unnecessary in Python.
>>>>>
>>>>
>>>> It's necessary everywhere we interface with C APIs and binary formats
>>>> that use them. Even the stdlib is full of candidates--the flags in os,
>>>> stat, etc. are all bitmasks.
>>>>
>>>
>>> I think that viewing the Python programmer community at large, very few
>>> actually interact with C APIs that have bitmasked flags.
>>>
>>
>> I don't see why this even needs to be established. We have cases like,
>> e.g., mmap.mmap all over the stdlib that take bitmasked flags. Are you
>> arguing that these functions are too uncommon to belong in the stdlib or
>> need to be redesigned?
>>
>>
>>
>> And, even if you don't touch any of those parts of the stdlib, there are
>> many outside libraries that follow its example. From the "first steps" of
>> the wx tutorial:
>>
>> window = wx.Frame(None, style=wx.MAXIMIZE_BOX | wx.RESIZE_BORDER
>> | wx.SYSTEM_MENU | wx.CAPTION | wx.CLOSE_BOX)
>>
>
> With a BitMask this could be:
>
>     window = wx.Frame(None, style=wx.Style('MAXIMIZE_BOX|**
> RESIZE_BORDER|SYSTEM_MENU|**CAPTION|CLOSE_BOX'))
>
>
>
>  This isn't some design quirk of wx; this is how nearly every GUI
>> framework except tkinter works. And image processing, audio processing,
>> platform glue like win32api and PyObjC, and countless other application
>> areas.
>>
>>  Moreover, a NamedInt can fit the bill without needing a specific bitmask
>>> flag.
>>>
>>
>>
>>  If you have "names" for your flag constituents you can just join them
>>> with '|' as in C. This is similar to what's currently being done in modules
>>> like os and stat, but provides conveniently printable names for the magic
>>> numbers. The benefits of a specific bitmasking class in the stdlib are imho
>>> very marginal.
>>>
>>
>>
>> The benefits of a bitmasking enum class are exactly the same as the
>> benefits of an ordered enum class. Compare:
>>
>>      background, edge = color.RED, side.BOTTOM
>>      print(background, edge)
>>      print(background < edge)
>>
>> The benefits of NamedInt are that this doesn't print "1 4" and then
>> "True".
>>
>
> Hopefully you meant BitMask, as a NamedInt would result in True (unless
> either color or side were not NamedInts).
>
> While a BitMask is not directly an int, Barry showed how it turns into an
> int when passed to a C library.
>
>
>
>  Now:
>>
>>
>>      style = wx.styles.MAXIMIZE_BOX | wx.styles.RESIZE_BORDER
>>      print(style)
>>      print(style & wx.keycodes.TAB)
>>
>> The benefits of a NamedInt are that this doesn't print "2098176" and then
>> "True".
>>
>> If we don't have these benefits, there is no reason to add NamedInt in
>> the first place, because it's nothing more than an alternate way to
>> construct integer constants.
>>
>
> How valuable is a name?  And a doc string?  Currently I'm working with
> OpenERP code, which uses constants in a lot of key places.  I would love to
> know what 5 stands for, and 6.  I knew 6 once, kind of, for about ten
> minutes while I worked with it, and now I've forgotten.
>
> --
> ~Ethan~
>
> ______________________________**_________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/**mailman/listinfo/python-ideas<http://mail.python.org/mailman/listinfo/python-ideas>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130312/840cd05d/attachment.html>