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

[Nick Coghlan]

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