Nick writes:

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.

Guido writes:

I can't make myself care about this. The code is broken. You get an error message.

Nick writes:

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.

If I'm understanding the situation here correctly, I'd like to chime in on Nick's side. I'm unconcerned about the bit of code that uses or misuses Context objects... I'm more concerned about the bit of the manual that describes (in simple words that "fit your brain") how attribute/method resolution works in Python. Right now, we say that there's one rule for all *normal* attributes and methods, and a slightly different rule for all double-underbar methods. (I'd summarize the rules here, but they're just sufficiently complex that I'm sure I'd make a mistake and wind up having people correct my mistake. Suffice to say that the difference between normal and double-underbar lookup has to do with checking (or not checking) the instance dictionary.) With the current state of the code, we'd need to say that there's one rule for all *normal* attributes and a slightly different rule for all double-underbar methods except for __context__ which is just like a normal attribute. That feels too big for my brain -- what on earth is so special about __context__ that it has to be different from all other double-underbar methods? If it were __init__ that had to be an exception, I'd understand, but __context__? -- Michael Chermside