[Python-ideas] Enums

[Michael Foord]

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
> effort.
>
>
>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
/ nt
* 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
flags)
* 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
though
* dis has flags in COMPILER_FLAG_NAMES, which are then set as locals in
inspect
* 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
*as* integers:

http://mail.python.org/pipermail/python-dev/2010-November/105916.html

All the best,

Michael Foord



> 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).
> e
> 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
> repr.
>
> 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
>> http://mail.python.org/mailman/listinfo/python-ideas
>>
>
>
>
> --
>
> http://www.voidspace.org.uk/
>
> 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
>
>
>


-- 

http://www.voidspace.org.uk/

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...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110725/85deb57a/attachment.html>