fuzzyman at gmail.com
Mon Jul 25 19:06:56 CEST 2011
On 25 July 2011 17:46, Michael Foord <fuzzyman at gmail.com> wrote:
> On 25 July 2011 01:33, Guido van Rossum <guido at python.org> wrote:
>> On Sun, Jul 24, 2011 at 3:47 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> > We've actually been down the 'namespace object' road years ago (Steve
>> > Bethard even wrote a proto-PEP IIRC) and it suffered the same fate as
>> > most enum PEPs: everyone has slightly different ideas on what should
>> > be supported, so you end up being faced with one of two options:
>> > 1. Ignore some of the use cases (so some users still have to do their
>> own thing)
>> > 2. Support all of the use cases by increasing the API complexity (so
>> > many users will still do their own thing instead of learning the new
>> > API)
>> For enums, I think we should just pick a solution. I'm in favor of
>> Barry Warsaw's version, flufl.enum.
> I generally like the flufl.enum API. There are two things it doesn't do.
> 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
>From the thread last year:
Python standard library modules currently using integers for constants:
* re - has flags (OR'able constants) defined in sre_constants, each flag has
two names (e.g. re.IGNORECASE and re.I)
* os has SEEK_SET, SEEK_CUR, SEEK_END - **plus** those implemented in posix
* doctest has its own flag system, but is really just using integer flags /
constants (quite a few of them)
* token has a tonne of constants (autogenerated)
* socket exports a bunch of constants defined in _socket
* gzip has flags: FTEXT, FHCRC, FEXTRA, FNAME, FCOMMENT
* errno (builtin module)
EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, EINVAL,
ENOTCONN, ESHUTDOWN, EINTR, EISCONN, EBADF, ECONNABORTED
* opcode has HAVE_ARGUMENT, EXTENDED_ARG. In fact pretty much the whole of
opcode is about defining and exposing named constants
* msilib uses flag constants
* multiprocessing.pool - RUN, CLOSE, TERMINATE
* multiprocessing.util - NOTSET, SUBDEBUG, DEBUG, INFO, SUBWARNING
* xml.dom and xml.dom.Node (in __init__.py) have a bunch of constants
* xml.dom.NodeFilter.NodeFilter holds a bunch of constants (some of them
* xmlrpc.client has a bunch of error constants
* calendar uses constants to represent weekdays, plus one for the EPOCH that
is best left alone
* http.client has a tonne of constants - recognisable as ports / error codes
* dis has flags in COMPILER_FLAG_NAMES, which are then set as locals in
* io defines SEEK_SET, SEEK_CUR, SEEK_END (same as os)
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.
Here's an email from Guido from that thread putting his vote in for enums
All the best,
> 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).
> 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.
> It would be nice to add support for or'ing of enums whilst retaining a nice
> 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.
> All the best,
> Michael Foord
>> --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
>> Python-ideas mailing list
>> Python-ideas at python.org
> May you do good and not evil
> May you find forgiveness for yourself and forgive others
> May you share freely, never taking more than you give.
> -- the sqlite blessing http://www.sqlite.org/different.html
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas