<div dir="ltr"><div>Thanks for the insights, Raymond. I don't think anyone is planning on rushing anything. We still have to get the enum module itself committed and a serious review process has just started for that, so it will take time.<br>

<br>There's no general "let's replace all constants with enums" TODO item that I know of. It's my hope that such changes will happen very gradually and only when deemed important and useful by core developers. So it's not different from any other changes made in the Python repository, really. Issues will be opened, discussed, code will be reviewed by whomever is willing to participate.<br>

<br></div>IIRC Guido wanted to have a printable representation for the socket module constants like socket.AF_* and socket.SOCK_* because that would be useful in developing Tulip. Implementing those with IntEnum may be a relatively non-controversial first foray into actually putting enums to use. But again, at least as far as I'm concerned there's no concrete todo list at this point.<br>

<br>Eli<br><br><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 12, 2013 at 4:49 PM, Raymond Hettinger <span dir="ltr"><<a href="mailto:raymond.hettinger@gmail.com" target="_blank">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">After the long design effort for the enum module,<br>
I'm sure there will be a forthcoming effort to apply<br>
them pervasively throughout the standard library.<br>
<br>
I would like to ask for a little restraint and for there to<br>
be individual cost/benefit evaluations for each case.<br>
<br>
On the plus-side, the new integer-enums have a better<br>
repr than plain integers.<br>
<br>
For internal constants such as those in idlelib and regex,<br>
the user won't see any benefit at all.  But there will be<br>
a cost in terms of code churn, risk of introducing errors<br>
in stable code, modestly slowing-down the code, making<br>
it more difficult to apply bug fixes across multiple versions<br>
of Python, and increased code verbosity (i.e. changing<br>
"if direction=LEFT: ..."  to "if direction is Direction.LEFT: ...")<br>
<br>
For external constants, some thought needs to be given to:<br>
* is the current API working just fine (i.e. decimal's ROUND_DOWN)<br>
* will enums break doctests or any existing user code<br>
* will it complicate users converting from Python 2<br>
* do users now have to learn an additional concept<br>
* does it complicate the module in any way<br>
<br>
I'm hoping that enums get used only in cases where they<br>
clearly improve the public API (i.e. cases such as sockets<br>
that have a large number of integer constants) rather<br>
than having a frenzy of every constant, everywhere getting<br>
turned into an enum.<br>
<br>
I would like to see enums used as tool for managing complexity,<br>
rather than becoming a cause of added complexity by being used<br>
for every problem, the tall and small, even where it is not needed at all.<br>
<br>
my-two-cents-ly yours,<br>
<br>
<br>
Raymond<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/eliben%40gmail.com" target="_blank">http://mail.python.org/mailman/options/python-dev/eliben%40gmail.com</a><br>
</blockquote></div><br></div></div></div></div>