[Python-Dev] Proposed resolutions for open PEP 343 issues

Nick Coghlan ncoghlan at gmail.com
Tue Oct 25 23:55:15 CEST 2005

Guido van Rossum wrote:
> On 10/25/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Almost there - this is the only issue I have left on my list :)
> [,,,]
>>> Why are you so keen on TypeError? I find AttributeError totally
>>> appropriate. I don't see symmetry with for-loops as a valuable
>>> property here. AttributeError and TypeError are often interchangeable
>>> anyway.
>> The reason I'm keen on TypeError is because 'abstract.c' uses it consistently
>> when it fails to find a method to support a requested protocol.
> Hm. abstract.c well predates the new type system. Slots and methods
> weren't really unified back then, so TypeError made obvious sense at
> the time.

Ah, I hadn't considered that, because I never made significant use of any 
Python versions before 2.2.

Maybe there's a design principle in there somewhere:

   Failed duck-typing -> AttributeError (or TypeError for complex checks)
   Failed instance or subtype check -> TypeError

Most of the functions in abstract.c handle complex protocols, so a simple 
attribute error wouldn't convey the necessary meaning. The context protocol, 
on the other hand, is fairly simple, and an AttributeError tells you 
everything you really need to know.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list