Is this a super bug?

[Bjorn Pettersen]

> From: Michele Simionato [mailto:mis6 at pitt.edu] 
> 
> "Bjorn Pettersen" <BPettersen at NAREX.com> wrote in message 
> news:<mailman.1050811779.16487.python-list at python.org>...
> 
> > <snip> this is the sequence that "should" happen:
> > 
> > 1  super(ff, f)[0]  # f == self
> > 2  superinst(type:<class ff>, obj:f)[0]
> > 3  si.  getitem  (0)
> > 4    si.  getattr  ('  getitem  ')
> > 5    .. return str.  dict  ['  getitem  '].  get  (f)
> > 6    boundmethod(str.  getitem  , f)
> > 7  bmeth(0)
> > 8   'a'
> 
> I don't understand what you are trying to say here ... 

Special method lookup goes through the class, and since the class is
Super, not obj.__class__, they can't be trapped through __getattr__.
(And for some reason they can't be trapped in a metaclass either...?)

[...]
> You may do that, but I don't like it. I like the fact that
> 
> super(cls,self)[index]
> 
> is *not* equivalent to
> 
> super(cls,self).__getitem__(index)

Most languages only define super.m(...) in object foo (class Foo,
superclass Foobase), and then to be equivalent to calling
Foobase::m(foo, ...).

Since Python has special attribute lookup rules for some attributes, the
normal extension would be to define super as an object with data
attributes from foo, and method attributes from Foobase. But that is not
even correct, it has to have the method attributes from Foo, except when
calling foo.m will call Foobase::m, but if Foobase::m calls m2, it will
start lookup in Foo.

One property this has is that given an empty subclass:

  class Foo : Foobase: pass

and a program context C with a hole, C[*] (i.e. C gives the value of the
program once you put a value in the hole), then:

   C[self] == C[super]

proving properties in this half-baked scheme is much harder.

> The present behaviour is the natural one, when you realize that super
> objects are attribute descriptors. In other words:
> 
> super(cls,self) is *not* self

You're objectively correct, however I'm missing the part where you're
saying this is good because...

> In you case 'self' is a string and has a __getitem__ method; 
> nevertheless, since super(cls,self) is a descriptor and not a string,
I 
> would not expect it to have a __getitem__ method, nor the other
methods of a string. 

... yet you want it to behave like if it had e.g. a find method... why
the inconsistency?

> What happens in reality (disclaimer: I don't know nothing about the C 
> implementation, I am guessing here) is that super(cls,self) has a 
> __getattribute__ method that call the methods of the string 
> object: the 
> fact that you can write
> 
> super(cls,self).__getitem__(index)
> 
> does *not* means that super(cls,self) has a __getitem__ method.

No but it means that when I ask for one it will get one..., first,
recall that 

  obj.meth.__get__(None, obj) is an unbound method

while

  m = obj.meth.__get__(ObjClass, obj) is a bound method

when saying obj.meth, you're doing the latter which means:

  1. if the instance contains the bound method, return it.
  2. if the class contains an unbound method with this name
     bind it to the object (create a bound method object
     and return it.

And then the special case semantics:

  obj[x]

calls ObjClass.__getitem__(self, x) directly, not going through the
steps above (thus my confustion that I can't trap it in the metaclass).
Thus, if I ask for __getitem__ by name, we follow the general rules, if
the __getitem__ semantics is invoked indirectly through subscripting, we
follow the special rules.

> I agree this can be confusing at first. The solution would be to
> document ``super`` and the attribute descriptors. 

No, the first thing is to define what we would like to use this concept
for, then we can decide which properties it must have, and then we can
come up with an implementation that is useful, not merely confusing.

> Maybe one of these days I will collect my notes and fill this gap,
> but this would require at least 20-30 pages, so it would take some
> time ...

That would be interesting to read... If I get time I'll try to implement
my semantics... The metaclass issue should make for a lot of typing...

-- bjorn