<br><br><div class="gmail_quote">On 25 July 2011 19:47, Raymond Hettinger <span dir="ltr"><<a href="mailto:raymond.hettinger@gmail.com">raymond.hettinger@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Jul 25, 2011, at 1:06 PM, Michael Foord wrote:</div><blockquote type="cite"><div class="gmail_quote"><div><font color="#000000"><br></font> Python standard library modules 
currently using integers for constants:
<br>
<br>* re - has flags (OR'able constants) defined in sre_constants, each flag 
has two names (e.g. re.IGNORECASE and re.I)
<br></div></div></blockquote><div><br></div></div><div>What is being proposed here?  Will there be a new namespace so that we would start writing re.Flags.IGNORECASE instead of re.IGNORECASE?  Are module level constants now going to be considered bad-form?</div>
<div><br></div><div>If constants switch from re.IGNORECASE to re.flags.IGNORECASE, are there any benefits to compensate for being both wordier and slower?</div><div class="im"><div><br></div></div></div></div></blockquote>
<div><br>Nope. Just something like this at the module level.<br><br>IGNORECASE = Flags.IGNORECASE <br><br>What it gains you is a nicer representation when looking at the values when debugging. On the other hand being able to have access to all the constants namespaced on a single object (as well) doesn't seem like such a bad thing.<br>
<br>Michael<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div class="im"><div></div>
<br><blockquote type="cite"><div class="gmail_quote"><div>* os has SEEK_SET, SEEK_CUR, SEEK_END - <b><span>*</span>plus<span>*</span></b> those implemented in 
posix / nt
<br></div></div></blockquote><div><br></div></div><div>Ditto</div><div class="im"><br><blockquote type="cite"><div class="gmail_quote"><div>* doctest has its own flag system, but is really just using integer 
flags / constants (quite a few of them)
<br>* token has a tonne of constants (autogenerated)
<br>* socket exports a bunch of constants defined in _socket
<br>* gzip has flags: FTEXT, FHCRC, FEXTRA, FNAME, FCOMMENT
<br>
<br>* errno (builtin module)
<br>
<br>EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, EINVAL,
<br>ENOTCONN, ESHUTDOWN, EINTR, EISCONN, EBADF, ECONNABORTED
<br></div></div></blockquote><div><br></div></div>It seems to me that an enum module or class doesn't make any of this code better.</div><div>AFAICT enums are a fat solution to a thin problem.</div><div><br></div><div>
Since python makes it so easy to put constants in class namespaces</div><div>and module namespaces, there is much less need for enums than in</div><div>statically compiled languages.  I think the perceived need is really</div>
<div>more of a carry-over coding habit than an actual need.  </div><div><br></div><div>That being said, this proposal seems to have momentum,</div><div>so it is going happen anyway.  Once introduced, people will</div><div>
think we've endorsed enums as the one right way to code</div><div>constants, so we will start to see them everywhere.  </div><div>Expect enums to become ubiquitous.</div><div><div><br></div><font color="#888888"><div>
<br></div><div>Raymond</div></font></div></div></blockquote></div><br><br clear="all"><br>-- <br><pre cols="72"><a href="http://www.voidspace.org.uk/" target="_blank">http://www.voidspace.org.uk/</a><br><br>May you do good and not evil<br>
May you find forgiveness for yourself and forgive others<br>May you share freely, never taking more than you give.<br>-- the sqlite blessing <a href="http://www.sqlite.org/different.html" target="_blank">http://www.sqlite.org/different.html</a></pre>

<br>