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

[Eli Bendersky]

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>