<div dir="ltr"><div><div><div><div><div>1) Is there limitation that EnumValues themselves must be immutable?<br><br></div>2)
 I'm most excited by the prospect of using these Enums as function 
defaults. I've not worked it through fully, but I'm 
guessing the following will work?<br><br></div><div style="margin-left:40px"><span style="font-family:courier new,monospace">>>> class Colors(Enum):<br>...        red = (256, 0, 0)<br><br>>>> def fill(color=Colors.red):<br>
...    pass<br>... <br>>>> from inspect import signature<br>>>> print(signature(fill))<br>(color=<EnumValue: Colors.red [value=(256, 0, 0)]>)<br></span></div></div><div><br><br></div><div>3)
 Enums are generally used for defining constants - Is there a case to be 
made for using capitals in the 435 as PEP8 suggests, or are enums a special case? 
(<a href="http://www.python.org/dev/peps/pep-0008/#constants">http://www.python.org/dev/peps/pep-0008/#constants</a>)<br></div></div><div><br></div><div>4) Is there an easy way to create custom EnumValues subclasses? In particular it'd be nice to be able to change the __repr__ in some cases to hide the value itself, which is often not important.<br>
</div><div><br><br>Sorry if this has already been discussed elsewhere (I've only recently signed up to the dev mailinglist).</div><div><br><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 12 April 2013 16:23, R. David Murray <span dir="ltr"><<a href="mailto:rdmurray@bitdance.com" target="_blank">rdmurray@bitdance.com</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 Fri, 12 Apr 2013 10:50:44 -0400, Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br>
> Nick brought this up in private email, and my response was basically that<br>
> iteration order for Enums should not be guaranteed, even if that happens to<br>
> work in the current implementation.  The reason why it works in the current<br>
> implementation is purely to provide predictable reprs.<br>
><br>
> Of course, we could sort the values for the repr and remove the sorted() call<br>
> in EnumMetaclass.__iter__() but then we would have to add it back for<br>
> IntEnums, since we *do* want to make explicit iteration order guarantees for<br>
> IntEnums, as they also have full rich comparisons.  I'm just not sure it's<br>
> worth it from an implementation point of view.<br>
><br>
> I will update the PEP to make this more clear.<br>
<br>
</div>OK.<br>
<div class="im"><br>
> >In talking to an existing internet protocol it would be natural to use<br>
> >IntEnum and this issue would not arise, but I have recently worked on<br>
> >an application that had *exactly* the above sort of enumeration used<br>
> >internally, when it would have been totally appropriate to use Enum rather<br>
> >than IntEnum.  The ap has several places where an ordered comparison<br>
> >against the enum is used to check if a code is in the error range or not.<br>
><br>
> Why Enums and not IntEnums?  Enums will not have ordered comparisons, but<br>
> IntEnums will.<br>
<br>
</div>To take advantage of their incommensurability with other Enums.  It's<br>
not a big deal, though; I'm more concerned that the API be internally<br>
consistent.  I presume that one could always define an Enum subclass<br>
and provide comparison methods if desired :)<br>
<span class="HOEnZb"><font color="#888888"><br>
--David<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/pelson.pub%40gmail.com" target="_blank">http://mail.python.org/mailman/options/python-dev/pelson.pub%40gmail.com</a><br>
</div></div></blockquote></div><br></div>