<div dir="ltr"><br><div class="gmail_extra"><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></blockquote></div><br></div><div class="gmail_extra">I don't feel strongly about allowing ()-lookup in addition to []-lookup, but in this paragraph the issue of multiple definitions has sneaked in :-) flufl.enum disallows this:<br>

<br>class Color(Enum):<br></div><div class="gmail_extra">  red = 1<br></div><div class="gmail_extra">  blue = 2<br></div><div class="gmail_extra">  green = 1 # oops!<br><br></div><div class="gmail_extra">Has it been decided that this is now allowed? If this is indeed the case, then Color(1) is a problem. The options are:<br>

<br></div><div class="gmail_extra">A. Return either Color.red or Color.green<br></div><div class="gmail_extra">B. Throwing an error<br><br></div><div class="gmail_extra">Do we have a decision on this? Personally I think the latter is better; the former is error prone and doesn't seem to be useful too often.<br>

<br>Eli [trying to tie loose ends for updating the PEP].<br><br></div><div class="gmail_extra"><br><br><br><br></div></div>