<br><br><div class="gmail_quote">On 25 July 2011 17:46, Michael Foord <span dir="ltr"><<a href="mailto:fuzzyman@gmail.com">fuzzyman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On 25 July 2011 01:33, 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">
On Sun, Jul 24, 2011 at 3:47 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
> We've actually been down the 'namespace object' road years ago (Steve<br>
> Bethard even wrote a proto-PEP IIRC) and it suffered the same fate as<br>
> most enum PEPs: everyone has slightly different ideas on what should<br>
> be supported, so you end up being faced with one of two options:<br>
> 1. Ignore some of the use cases (so some users still have to do their own thing)<br>
> 2. Support all of the use cases by increasing the API complexity (so<br>
> many users will still do their own thing instead of learning the new<br>
> API)<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></blockquote></div><div><br>I generally like the flufl.enum API. There are two things it doesn't do.<br><br>For new apis it is *usually* possible to just use strings rather than integers - and have your library do the mapping if an underlying api takes integers. For existing ones, for example many parts of the python standard library, we couldn't replace the integer values with enums without a lot of effort.<br>
<br></div></div></blockquote><div><br>From the thread last year:<br><br> Python standard library modules
currently using integers for constants:
<br>
<br>* re - has flags (OR'able constants) defined in sre_constants, each flag
has two names (e.g. re.IGNORECASE and re.I)
<br>* os has SEEK_SET, SEEK_CUR, SEEK_END - <b class="moz-txt-star"><span class="moz-txt-tag">*</span>plus<span class="moz-txt-tag">*</span></b> those implemented in
posix / nt
<br>* doctest has its own flag system, but is really just using integer
flags / constants (quite a few of them)
<br>* token has a tonne of constants (autogenerated)
<br>* socket exports a bunch of constants defined in _socket
<br>* gzip has flags: FTEXT, FHCRC, FEXTRA, FNAME, FCOMMENT
<br>
<br>* errno (builtin module)
<br>
<br>EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, EINVAL,
<br>ENOTCONN, ESHUTDOWN, EINTR, EISCONN, EBADF, ECONNABORTED
<br>
<br>* opcode has HAVE_ARGUMENT, EXTENDED_ARG. In fact pretty much the whole
of opcode is about defining and exposing named constants
<br>* msilib uses flag constants
<br>* multiprocessing.pool - RUN, CLOSE, TERMINATE
<br>* multiprocessing.util - NOTSET, SUBDEBUG, DEBUG, INFO, SUBWARNING
<br>* xml.dom and xml.dom.Node (in __init__.py) have a bunch of constants
<br>* xml.dom.NodeFilter.NodeFilter holds a bunch of constants (some of them
flags)
<br>* xmlrpc.client has a bunch of error constants
<br>* calendar uses constants to represent weekdays, plus one for the EPOCH
that is best left alone
<br>* http.client has a tonne of constants - recognisable as ports / error
codes though
<br>* dis has flags in COMPILER_FLAG_NAMES, which are then set as locals in
inspect
<br>* io defines SEEK_SET, SEEK_CUR, SEEK_END (same as os)
<br>
<br>Where constants are implemented in C but exported via a Python module
(the constants exported by os and socket for example) they could be
wrapped. Where they are exported directly by a C extension or builtin
module (e.g. errno) they are probably best left.
<br>
<br>Here's an email from Guido from that thread putting his vote in for enums *as* integers:<br><br><a href="http://mail.python.org/pipermail/python-dev/2010-November/105916.html">http://mail.python.org/pipermail/python-dev/2010-November/105916.html</a><br>
<br>All the best,<br><br>Michael Foord<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>If the flufl enums subclassed integer then replacing most of the existing constants in the standard library would be trivially easy (so we'd have a built-in use case).<br>
e<br>
The second use case, where you really do want to use integers rather
than strings, is where you have flag constants that you "or" together.
For example in the standard library we have these in r, gzip, msilib, some in xml.dom.NodeFilter, plus a bunch of others.<br><br>It would be nice to add support for or'ing of enums whilst retaining a nice repr.<br><br>
I did collect a whole lot of emails from a thread last year and was hoping to put a pep together. I'd support flufl.enum - but it would be better if it was extended so we could use it in the standard library.<br><br>
All the best,<br>
<br>Michael Foord<br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<font color="#888888"><br>
--<div class="im"><br>
--Guido van Rossum (<a href="http://python.org/%7Eguido" target="_blank">python.org/~guido</a>)<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div></font></blockquote></div><br><br clear="all"><br>-- <br><pre cols="72"><a href="http://www.voidspace.org.uk/" target="_blank">http://www.voidspace.org.uk/</a><br><br>May you do good and not evil<br>May you find forgiveness for yourself and forgive others<br>
May you share freely, never taking more than you give.<br>-- the sqlite blessing <a href="http://www.sqlite.org/different.html" target="_blank">http://www.sqlite.org/different.html</a></pre>
<br>
</blockquote></div><br><br clear="all"><br>-- <br><pre cols="72"><a href="http://www.voidspace.org.uk/" target="_blank">http://www.voidspace.org.uk/</a><br><br>May you do good and not evil<br>May you find forgiveness for yourself and forgive others<br>
May you share freely, never taking more than you give.<br>-- the sqlite blessing <a href="http://www.sqlite.org/different.html" target="_blank">http://www.sqlite.org/different.html</a></pre>
<br>