On 14 Feb 2013 02:39, "Antoine Pitrou"
Le Wed, 13 Feb 2013 14:07:48 +1000, Nick Coghlan
a écrit : On 13 Feb 2013 09:11, "Tim Delaney"
wrote: On 13 February 2013 09:56, Guido van Rossum
wrote: Frankly, enums are not that useful in small programs. For large programs or libraries, and especially for public APIs, the extra cost of defining the enum shouldn't count against them.
Let's just import Barry's enums into the stdlib.
That's entirely your call. FWIW I probably won't use them, as they fail
to meet my needs for an enum, #1 being not having to specify their values in any way if I don't want to. Once you get past 3 or 4 values, it's too easy to miss or reuse a value.
What's wrong with enum.make? That just accepts the sequence of names namedtuple style, no values specified anywhere.
What's wrong is that TSBOOWTDI. With enum and enum.make, you have two different idioms for declaring enums, while a single class-based definition style should suffice.
Really? What happened to the principle of layered API complexity, where a simple *convenience* function is the obvious way to do it for the cases it covers, while the full, more powerful, but also more verbose, explicit subclassing API covers the more complex cases? Magic namespaces and metaclasses sure don't meet *my* definition of obvious. A normal subclassing API with a convenience function for simple cases? That's just good layered API design. Cheers, Nick.
Regards
Antoine.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas