On Sat, Feb 23, 2013 at 9:04 AM, Antoine Pitrou <solipsis at pitrou.net> wrote: > On Sat, 23 Feb 2013 08:27:50 -0800 > Eli Bendersky <eliben at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130223/7ea09a62/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4