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

Eric Snow ericsnowcurrently at gmail.com
Sat Feb 23 20:35:11 CET 2013

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

More information about the Python-Dev mailing list