[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as (original) (raw)

Anders J. Munch ajm at flonidan.dk
Wed Feb 27 17:34:35 CET 2013


Hi, offering my DKK 0.50 on the subject. I've used an in-house enum type for the better part of a decade - put up at http://unicollect.dk/download/oss/dc_enum.zip for inspiration.

I'm partial to an int subclass, or at least something very int-like, because wrapping C libraries is such a major use case. Enums should support all the operations that C enum's do: indexing, ordering, bitwise math and unnamed values.

There's a whole bunch of these wrapped C enum's in the standard library, e.g. in the os, stat and urllib modules. Wouldn't it be good to see them converted to enumeration values, to make them sort-of self-documenting and sort-of typechecked?

This should not raise an exception: 5 is the perfectly valid combination of XOTH and ROTH. Supporting unnamed values is also useful when reading integer values from an external source - file, network, serial port - where typically you'd first convert the received value to the enum type before doing any processing. If converting to enum type may raise an exception, that would force you to print raw integer values in diagnostics, where you'd rather have printed the userfriendly symbolic names.

SI.ROTH S_I.ROTH SI(4) S_I.ROTH SI(5) S_I(5) print(SI(4)) S_I.ROTH(4) print(SI(5)) S_I.?(5)

regards, Anders



More information about the Python-Dev mailing list