On 23/11/2010 13:41, Nick Coghlan wrote:
On Tue, Nov 23, 2010 at 2:46 AM,<exar...@twistedmatrix.com> wrote:
On 04:24 pm, solip...@pitrou.net wrote:
On Mon, 22 Nov 2010 17:08:36 +0100
Hrvoje Niksic<hrvoje.nik...@avl.com> wrote:
On 11/22/2010 04:37 PM, Antoine Pitrou wrote:
+1. The problem with int constants is that the int gets printed, not
the name, when you dump them for debugging purposes :)
Well, it's trivial to subclass int to something with a nicer __repr__.
PyGTK uses that technique for wrapping C enums:
Nice. It might be useful to add a private _Constant class somewhere for
stdlib purposes.
http://www.python.org/dev/peps/pep-0354/
Indeed, it is difficult to do enums is such a way that they feel
sufficiently robust to be worth the effort of including them (although
these days, I would be inclined to follow the namedtuple API style
rather than that presented in PEP 354).
Right. As it happens I just submitted a patch to Barry Warsaw's enum
package (nice), flufl.enum [1], to allow namedtuple style creation of
named constants:
>>> from flufl.enum import make_enum
>>> Colors = make_enum('Colors', 'red green blue')
>>> Colors
<Colors {red: 1, green: 2, blue: 3}>
PEP 354 was rejected for two primary reasons - lack of interest and
nowhere obvious to put it. Would it be *so bad* if an enum type lived in
its own module? There is certainly more interest now, and if we are to
use something like this in the standard library it *has* to be in the
standard library (unless every module implements their own private
_Constant class).
Time to revisit the PEP?
All the best,
Michael
[1] https://launchpad.net/flufl.enum
Cheers,
Nick.
--
http://www.voidspace.org.uk/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
