<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 28, 2013 at 9:09 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</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 Sun, Apr 28, 2013 at 3:28 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>


> Functions are descriptors, so this rule already covers ordinary methods. The<br>
> slight concern I have with making the duck typed exclusion only descriptors<br>
> (rather than descriptors and callables) is that it means things like<br>
> functools.partial objects will be treated as enum values rather than as<br>
> static methods. OTOH, explicitly wrapping such callables in staticmethod<br>
> should still work, so the simpler rule is probably better.<br>
<br>
</div>I think the practice of using callables (other than possibly decorated<br>
functions) as global variables is confusing at best, even in a<br>
non-enum class, since few people will be able to predict whether they<br>
will get the instance passed or not. So I think the rule looking only<br>
for descriptors is superior.<br>
<br>
There has been a whole lot more discussion in this thread. I am now<br>
asking everyone to stop bikeshedding, even if you think *your* point<br>
isn't bikeshedding -- the cacophony makes it impossible to hear<br>
anyone.<br>
<br>
There are a few more issues on which I'd like to pronounce.<br>
<br>
1. The order in which iter(Color) should produce the items. The<br>
argument has been made that definition order is the only order that is<br>
not easily reconstructed, and I agree. So let's use definition order,<br>
even if that means it can't be implemented in Python 2.<br>
<br>
2. Whether Color(x) should be allowed, and what it should mean. Taking<br>
the example of bool, it should return an existing enum if the argument<br>
is either a Color or one of the values used for Color items (choosing<br>
one somehow if there are multiple with the same value -- it doesn't<br>
matter which one), and raise an exception if the argument is neither.<br>
E.g.:<br>
<br>
  class Color(Enum):<br>
     red = 1<br>
     white = 2<br>
     blue = 3<br>
<br>
x = Color.red<br>
assert Color(x) is Color.red<br>
assert Color(1) is Color.red<br>
Color(42)  # raises<br>
<br>
(2a. We could also allow Color('red') is Color.red, but that could be<br>
confusing, and we can already do that with getattr(Color, 'red'), and<br>
bool('False') doesn't return False anyway, so let's not do that.)<br>
<br>
(2b. Let's not hypergeneralize and try to make bool and enums<br>
completely alike. I see no advantage to adding bool.True and<br>
bool.False, nor in making enums "final" classes, or giving a meaning<br>
to iter(bool). Type bool is its own thing, but that doesn't mean enums<br>
can't emulate aspects of it.)<br>
<br>
Together with my pronouncements earlier in this thread I am hoping<br>
that Eli and Barry will update the PEP and implementation (let's give<br>
them a week) and everyone else will quiet down. I realize we're<br>
deviating further from flufl.enum than our initial hope, but I think<br>
the outcome is better.<br></blockquote></div><br></div><div class="gmail_extra">Sounds like a plan. Thanks for trying to converge things, Guido. Personally I don't have strong opinions about the changes inflicted by recent threads, but I may stumble into something as I dive deeper. I was away for a couple of days and a lot has changed - I'll need some time to catch up, but updating the PEP by the end of the week seems reasonable.<br>

<br>Eli<br><br></div><div class="gmail_extra"><br><br></div></div>