On Sat, Feb 23, 2013 at 9:04 AM, Antoine Pitrou <solip...@pitrou.net> wrote:
> On Sat, 23 Feb 2013 08:27:50 -0800 > Eli Bendersky <eli...@gmail.com> wrote: > > > See also http://bugs.python.org/issue16801#msg178542 for another use > > > case for named values. > > > > > > I've seen an awful lot of code that uses global variables or class > > > attributes primarily to get name validation on constant values, and I > > > think all of that code would be a prime candidate for using Named > Values. > > > Some of them are also enum-like, but many of them are not. So I'm with > > > Nick on this one. > > > > Any suggestions for places in the stdlib where enums could come useful > will > > be most welcome > > The constants in the os module (os.SEEK_SET, etc.). > The constants in the socket module (socket.AF_INET, etc.). > And so on :-) > 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. The reason I make the *input* vs. *output* distinction, is that for stdlib code that returns values, the user may rely on their numeric values and if we switch to enum code will break. However, for os.SEEK_* this is not the case. Thee can be aliases for enums: class SeekKind(Enum): SEEK_SET = 0 SEEK_CUR = 1 SEEK_END = 2 SEEK_SET = SeekKind.SEEK_SET ... lseek() can be changed to call 'int' on its input, and now os.SEEK_* gain useful string representations when printed. Thoughts? Eli
_______________________________________________ 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
