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

[Eric Snow]

On Sat, Feb 23, 2013 at 10:46 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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).

+1

FWIW, I'm a fan of starting with a basic NamedValue API that avoids
the structure decisions.  The grouping question is valuable but a
GroupedConstant can build on a NamedValue.

-eric