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

Nick Coghlan ncoghlan at gmail.com
Sat Feb 23 18:46:39 CET 2013

On Sun, Feb 24, 2013 at 3:15 AM, Eli Bendersky <eliben at gmail.com> wrote:

Hmm, constants such as os.SEEK* which serve as inputs to stdlib rather than outputs can actually be a good candidate for enum without worrying about backwards compatibility.

Not true - users may be taking those values and passing them to third party APIs that expect them to be integers (since they're explicitly documented as such).

However, pitching this at the enum level also introduces a mandatory level of structure we may not care about. All of the arguments about enums and what they should and shouldn't allow happen at the higher level, to do with the relations between a group of named values, and how the members of the group interact with other data types.

For the standard library, we really don't care about any of those things, because we're currently using integers and strings for everything, so we can't add structure without risking breaking other people's code. However, just as we can get away with switching from producing and consuming tuples to producing and consuming namedtuples without breaking backwards compatibility, we could get away with producing and consuming names values in many cases, so long as those values behaved exactly like they did previously (i.e. as integers - there's little benefit to replacing our string "enums", since they're generally chosen for ease of debugging).

We can't replace errno values, or the os module seek constants, etc with something that doesn't transparently behave like an integer, because people may currently be using comparisons against their integer counterparts, or passing them to non-stdlib APIs which expect the numeric value. But we could probably get away with changing their repr (as well as switching them to subclasses of int rather than ordinary int objects).

Many other existing libraries would be in the same boat - backwards compatibility would be an insurmountable barrier to using enums, but they could use named values.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list