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

[Michael Chermside]

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