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

Nick Coghlan ncoghlan at gmail.com
Tue Oct 25 16:27:49 CEST 2005

Almost there - this is the only issue I have left on my list :)

Guido van Rossum wrote:
> On 10/24/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> However, those resolutions bring up the following issues:
>>    5 a. What exception is raised when EXPR does not have a __context__ method?
>>      b.  What about when the returned object is missing __enter__ or __exit__?
>>     I suggest raising TypeError in both cases, for symmetry with for loops.
>>     The slot check is made in C code, so I don't see any difficulty in raising
>>     TypeError instead of AttributeError if the relevant slots aren't filled.
> 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.

None of the abstract object methods currently raise AttributeError, and this
property is fairly visible at the Python level because the abstract API's are 
used to implement many of the bytecodes and various builtin functions. Both 
for loops and the iter function, for example, get their current exception 
behaviour from PyObject_GetIter and PyIter_Next.

Having had a look at mwh's patch, however, I've realised that going that way 
would only be possible if there were dedicated bytecodes for GET_CONTEXT, 
ENTER_CONTEXT and EXIT_CONTEXT (similar to the dedicated GET_ITER and FOR_ITER).

Leaving the exception as AttributeError means that level of bytecode hacking 
isn't necessary (mwh's patch just emits a fairly normal try/finally statement, 
although it still modifies the bytecode to include LOAD_EXIT_ARGS).

So, the inconsistency with other syntactic protocols still bothers me, but I 
can live with AttributeError if you don't want to add three new bytecodes just 
to support PEP 343.


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

More information about the Python-Dev mailing list