<div class="gmail_quote">2011/7/25 Barry Warsaw <span dir="ltr"><<a href="mailto:barry@python.org" target="_blank">barry@python.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Jul 24, 2011, at 05:33 PM, Guido van Rossum wrote:<br>
<br>
>For enums, I think we should just pick a solution. I'm in favor of<br>
>Barry Warsaw's version, flufl.enum.<br>
<br>
</div>Thanks!  I would be quite happy to see the library pulled into the stdlib, and<br>
I'd be willing to maintain a backward compatible standalone version for older<br>
Pythons.<br>
<br>
For me, the API has been quite stable.  The last thing I added was Michael<br>
Foord's make_enum() contribution, and PJE's fix for pickling.  I haven't felt<br>
a burning need to add anything else really in quite some time.<br></blockquote><div><br></div><div><br></div><div><div> >>> from flufl.enum import Enum</div><div> >>> class Colors(Enum):</div><div> ...     red = 1</div>

<div> ...     green = 2</div><div> ...     blue = 3</div></div><div><br></div><div>What I find uncomfortable with this is the extra "Colors" name space.</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
Say we change all the socket module constants to make use of this, what will we have?</div>
<div><br>>>> socket.AF_INET</div><div><EnumValue: Constants.AF_INET [int=2]></div><div><br></div><div>...and:</div><div><br></div><div>>>> socket.Constants.AF_INET</div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><EnumValue: Constants.AF_INET [int=2]></div>
<div><br></div><div>...? Is that correct?</div><div><br></div><div>Also:</div><div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>>>> socket.AF_INET</div><div><EnumValue: Constants.AF_INET [int=2]></div>
</div><div>>>> socket.AF_INET == 2</div><div>False</div><div>>>></div><div><br></div><div>This shouldn't be underestimated: I've seen code comparing against plain integers rather than constants more than once, and that code would eventually break.</div>
<div>Personally I've never felt the need of any kind of "enum" type. </div><div>On the other hand I would welcome a "named constant" type of some kind but IMO, it should remain a base integer and provide just a minimal extra layer of usability, such as:</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>class constant(int):</div><div><div>    """A constant type; overrides base int to provide a useful name on str()."""</div>
<div><br></div><div>    def __new__(cls, value, name, doc=None):</div><div>        inst = super(constant, cls).__new__(cls, value)</div><div>        inst._name = name</div><div>        if doc is not None:</div><div>            inst.__doc__ = doc</div>
<div>        return inst</div><div><br></div><div>    def __str__(self):</div><div>        return self._name</div><div><br></div><div>>>> STATUS_RUNNING = constant(0, "running")</div><div>>>> STATUS_RUNNING</div>
<div>0</div><div>>>> str(STATUS_RUNNING)</div><div>"running"</div><div>>>></div></div><div><br></div><div><br></div><div>In summary, I'm -1 about including this into the stdlib and change all the stdlib constants in accordarce.</div>
<div><br></div><div>My 2 cents.</div><div><br></div><div><br></div><div>--- Giampaolo</div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="http://code.google.com/p/psutil/downloads/list">http://code.google.com/p/pyftpdlib/</a></div>
<div><meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="http://code.google.com/p/psutil/downloads/list">http://code.google.com/p/psutil/</a></div><meta http-equiv="content-type" content="text/html; charset=utf-8"></div>