[Python-Dev] Best practices for Enum

Stephen J. Turnbull stephen at xemacs.org
Mon May 13 09:50:56 CEST 2013

Raymond Hettinger writes:

 > whether users will see any actual benefits (particularly for
 > internal constants).

I don't understand the parenthetical remark.  It seems to me that
changing internal constants should have the benefits that Ethan points
to for understanding, debugging, and interactive exploration, with the
least risk of destabilizing external APIs.

I agree with you that the *net* benefit is still likely to be negative
due to effects of code churn and the potential for new bugs, but
(considering benefit separately from cost) the advertised benefits
would be achieved.

The point is that I think it's clear that using enums to provide name
spaces for the large number of constants whose names are well-known,
but not so much the values, in the os module and other OS library
wrappers is highest priority, and IMO a net plus.  But I would say the
next place to look would be exactly these internal constants, where
they have similar characteristics (many of them, well-known names,
hard-to-remember values: the fds for stdin, stdout, and stderr are
non-candidates!)  As I said, *I* don't think it's worth doing internal
constants, but I couldn't defend that opinion well to somebody who
thinks it is worth doing.

More information about the Python-Dev mailing list