On Sun, Feb 24, 2013 at 3:15 AM, Eli Bendersky <eli...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
