[Python-Dev] enum discussion: can someone please summarize open issues?

[Nick Coghlan]

On 4 May 2013 00:17, "Eli Bendersky" <eliben at gmail.com> wrote:
>
>
>
>
> On Fri, May 3, 2013 at 6:34 AM, Greg Ewing <greg.ewing at canterbury.ac.nz>
wrote:
>>
>> Barry Warsaw wrote:
>>>
>>> I still don't get it why this is an issue though, or at least why this
is
>>> different than any other getattr on any other class,
>>
>>
>> It's not a problem that getattr() has this behaviour.
>> What I'm questioning is the idea that getattr() should
>> be the only provided way of doing a name->enum lookup,
>> because that will require everyone to do extra checks
>> to ensure safety.
>
>
> I'm just curious what it is about enums that sets everyone on a "let's
make things safer" path. Python is about duck typing, it's absolutely
"unsafe" in the static typing sense, in the most fundamental ways
imaginable. When programmatically invoking a method on a class (say some
sort of RPC), we don't check that the class is of the correct type. We
invoke a method, and if it quacks, that's a good enough duck. If it was
actually the wrong class, something will break later. EAFP Is a central
Python tenet, whether we like it or not. If one looks for static
guarantees, Python surely shouldn't be the preferred language, no?
>
> And concretely, how is this case different from any programmatic
attribute access in Python objects? You can pass dunders to getattr() and
it probably wasn't what you meant, but Python does not do this type
checking for you. Why is an Enum different than any other class?

The only reason to use enums at all is to improve logging and error
messages. Thus, designing the API and behaviour of an enum type is mostly a
matter of asking "What mistakes are developers likely to make?" and "How
can the enum design help guide them towards a suitable solution?". The
answers are a combination of API design and providing appropriate details
in error messages.

If a developer doesn't care about those two questions then they would just
use the raw underlying values.

Cheers,
Nick.

>
> Eli
>
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130504/1d589bf1/attachment.html>