On 23/11/2010 13:41, Nick Coghlan wrote:
> On Tue, Nov 23, 2010 at 2:46 AM,<exarkun at twistedmatrix.com> wrote:
>> On 04:24 pm, solipsis at pitrou.net wrote:
>>> On Mon, 22 Nov 2010 17:08:36 +0100
>>> Hrvoje Niksic<hrvoje.niksic at 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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4