On Sat, Feb 23, 2013 at 10:46 AM, Nick Coghlan <ncogh...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
