Sigh..<div><br></div><div>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..</div>
<div><br></div><div>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.</div>
<div><br></div><div>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..</div>
<div><br></div><div>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. <i>However,</i> 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<i> </i>int-enums. Problem solved.</div>
<div><br></div><div>(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..)</div><div><br>
</div><div>--Alex<br><br><div class="gmail_quote">On Tue, Mar 12, 2013 at 1:40 PM, Ethan Furman <span dir="ltr"><<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 03/12/2013 01:07 PM, Andrew Barnert wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: Eli Bendersky <<a href="mailto:eliben@gmail.com" target="_blank">eliben@gmail.com</a>><br>
Sent: Tuesday, March 12, 2013 10:28 AM<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Mar 12, 2013 at 9:59 AM, Andrew Barnert <<a href="mailto:abarnert@yahoo.com" target="_blank">abarnert@yahoo.com</a>> wrote:<br>
<br>
On Mar 12, 2013, at 8:36, Eli Bendersky <<a href="mailto:eliben@gmail.com" target="_blank">eliben@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br>
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.<br>
</blockquote>
<br>
I think that viewing the Python programmer community at large, very few actually interact with C APIs that have bitmasked flags.<br>
</blockquote>
<br>
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?<br>
<br>
<br>
<br>
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:<br>
<br>
window = wx.Frame(None, style=wx.MAXIMIZE_BOX | wx.RESIZE_BORDER<br>
| wx.SYSTEM_MENU | wx.CAPTION | wx.CLOSE_BOX)<br>
</blockquote>
<br></div>
With a BitMask this could be:<br>
<br>
window = wx.Frame(None, style=wx.Style('MAXIMIZE_BOX|<u></u>RESIZE_BORDER|SYSTEM_MENU|<u></u>CAPTION|CLOSE_BOX'))<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Moreover, a NamedInt can fit the bill without needing a specific bitmask flag.<br>
</blockquote>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br>
<br>
The benefits of a bitmasking enum class are exactly the same as the benefits of an ordered enum class. Compare:<br>
<br>
background, edge = color.RED, side.BOTTOM<br>
print(background, edge)<br>
print(background < edge)<br>
<br>
The benefits of NamedInt are that this doesn't print "1 4" and then "True".<br>
</blockquote>
<br></div>
Hopefully you meant BitMask, as a NamedInt would result in True (unless either color or side were not NamedInts).<br>
<br>
While a BitMask is not directly an int, Barry showed how it turns into an int when passed to a C library.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now:<br>
<br>
<br>
style = wx.styles.MAXIMIZE_BOX | wx.styles.RESIZE_BORDER<br>
print(style)<br>
print(style & wx.keycodes.TAB)<br>
<br>
The benefits of a NamedInt are that this doesn't print "2098176" and then "True".<br>
<br>
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.<br>
</blockquote>
<br></div>
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.<br>
<br>
--<br>
~Ethan~<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/<u></u>mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div><br></div>