<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 26, 2013 at 10:36 AM, 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="HOEnZb"><div class="h5">On Fri, Apr 26, 2013 at 10:33 AM, Glenn Linderman <<a href="mailto:v%2Bpython@g.nevcal.com">v+python@g.nevcal.com</a>> wrote:<br>


> On 4/25/2013 9:19 PM, Guido van Rossum wrote:<br>
><br>
> On Thu, Apr 25, 2013 at 8:39 PM, Glenn Linderman <<a href="mailto:v%2Bpython@g.nevcal.com">v+python@g.nevcal.com</a>><br>
> wrote:<br>
><br>
> an enumeration of objects whose class defines __call__ would<br>
> not be so weird.<br>
><br>
> Seriously? You'd complexificate the basic usage in order to cater for<br>
> such an esoteric use case? The *only* use cases that matter at all for<br>
> enum values are ints and strings, and even the latter could be<br>
> considered a luxury when compared to other languages' enums.<br>
><br>
><br>
> No, I'd look for a solution/implementation that doesn't divide objects into<br>
> "plain" and "esoteric" cases. Py3 now treats everything as objects. So an<br>
> enumeration should be able to deal with any object as a value.<br>
<br>
</div></div>I think you've lost track of the Zen of Python.<br></blockquote></div><br></div><div class="gmail_extra">I feel that this thread has lost track of it long ago. Some time back in the Enum discussions (some 350 messages ago or so), there was a proposal to have this:<br>

<br></div><div class="gmail_extra">class Color(Enum):<br></div><div class="gmail_extra">  RED, BLUE, GREEN<br><br></div><div class="gmail_extra">By doing some crazy-cool shenanigans. Although the syntax is great, it was rejected on the basis of being too magic.<br>

<br>The recent proposals of folding Enum and EnumValue into one, having class members be instances of the class they're members of while supporting a bunch of other Enum requirements also go off the rails in terms of complexity and magic.<br>

<br></div><div class="gmail_extra">In contrast, personally I feel the current proposal in PEP 435 has an appeal from the POV of simplicity. It really is a very nice separation of concerns between enum values and Enum as a container of such values. It even allows significant customization (IntEnum, etc) which is pretty simple to grok. It would be a shame to lose these for the sake of making Python a bit more like Java.<br>

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