[Python-Dev] Metaclass problem in the "with" statement semantics in PEP 343

Nick Coghlan ncoghlan at gmail.com
Tue Nov 29 11:48:31 CET 2005

Guido van Rossum wrote:
> On 11/28/05, Nick Coghlan <ncoghlan at iinet.net.au> wrote:
>> I think we need to fix the proposed semantics so that they access the slots
>> via the type, rather than directly through the instance. Otherwise the slots
>> for the with statement will behave strangely when compared to the slots for
>> other magic methods.
> Maybe it's because I'm just an old fart, but I can't make myself care
> about this. The code is broken. You get an error message. It even has
> the correct exception (TypeError). In this particular case the error
> message isn't that great -- well, the same is true in many other cases
> (like whenever the invocation is a method call from Python code).

I'm not particularly worried about the error message - as you say, it even has 
the right type. Or at least one of the two right types ;)

> That most built-in operations produce a different error message
> doesn't mean we have to make *all* built-in operations use the same
> approach. I fail to see the value of the consistency you're calling
> for.

The bit that more concerns me is the behavioural discrepancy that comes from 
having a piece of syntax that looks in the instance dictionary. No other 
Python syntax is affected by the instance attributes - if the object doesn't 
have the right type, you're out of luck.

Sticking an __iter__ method on an instance doesn't turn an object into an 
iterator, but with the current semantics, doing the same thing with 
__context__ *will* give you a manageable context.


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

More information about the Python-Dev mailing list