On 27 July 2011 13:44, M.-A. Lemburg <mal@egenix.com> wrote:

Raymond Hettinger wrote:
>
> On Jul 24, 2011, at 6:19 PM, Jack Diederich wrote:
>
>> On Sun, Jul 24, 2011 at 8:33 PM, Guido van Rossum <guido@python.org> wrote:
>>> For enums, I think we should just pick a solution. I'm in favor of
>>> Barry Warsaw's version, flufl.enum.
>>
>> I don't care for enums but enough other people do that I wouldn't mind
>> including a blessed implemenation.
>
> I also don't care for enums and recommend against adding them to the language.
> IMO, it is something that makes good sense in statically compiled languages
> and is unnecessary for us. Not to mention, we already have several ways to do it
> (module and class namespaces for example).
>
> Also, when this idea came up in the past, it tended to get shot down because
> the various use cases suggested differing implementations with different
> features.
>
> I also urge caution because Python has already stopped being a small language.
> Enums are especially problematic because they will pop up everywhere.
> You won't have the option of ignoring them.

+1

Actually, as they should behave exactly like constants you should entirely be able to "ignore" them (to the same extent you ignore the existing constants anyway).

Whether they're exposed at the module level, or grouped in a single namespace (the container), or both, is a stylistic issue for module authors. I've seen plenty of Python modules that group constants as class attributes for convenience even without an enum in the standard library. This proposal just makes those more useful and doesn't add any overhead for *using* them.

I think a lot of the objections come from perceived negative experience of Enums in other languages (not particularly aimed at you here MAL). When we discussed this on python-dev several developers were much happier with the proposal if we called them NamedConstants and GroupedConstants rather than Enums.

Michael

> Python has achieved an amazing adoption rate without enums.
> Most people just don't need them. Many, large and clean apps have
> been built without them. Those that have found did were typically
> able to implement them easily with the existing toolset.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Jul 27 2011)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
http://mail.python.org/mailman/listinfo/python-ideas