Question about accessing class-attributes.

[Bjorn Pettersen]

> From: Alex Martelli [mailto:aleax at aleax.it] 
> 
> Bjorn Pettersen wrote:
> 
> >> From: Alex Martelli [mailto:aleax at aleax.it]
> > [...]
> 
> [special-methods problem snipped]
> 
> Ah yes, I see now!  Yes, functions such as len() rely on slots in
> the type object, e.g. as you've noticed:
> 
[...]
> zone of the code.  Maybe you can post this as a bug in 2.3 beta 1
> on sourgeforge (ideally showing where in the docs it defines the
> semantics that it then doesn't respect) so we can get this looked
> at by the few people who really DO grasp these parts...;-).  There
> is probably some sound implementation reason for the current
> behavior, but if so it should be better documented, I think.

SF 729913. I have not been able to find an exact description of the
lookup rules for new-style classes anywhere.

> > The relevance this has to super, is that you couldn't do a 
> > (contrived) example like:
> > 
> >   for item in super(MyClass, self):
> >       ...
> > 
> > (in general, you can't pass super(MyClass, self) to a 
> > function expecting a MyClass instance, even if MyClass 
> > defines no new behavior...)
> 
> Yes, of course not -- super(MyClass, self) is NOT an instance 
> of MyClass (isn't THAT why you're calling super...?).  

I'm also missing an exact description of what super() returns. It looks
like it's an object that when you call method 'm', invokes the proper
super class' method 'm', and if that 'm' invokes any otherm method,
'm2', the original objects definiton 'm2' is used. So it looks like it
should be substitutable, or at least a first class object, but as you
said: "of course not". Am I missing some documentation, or is it
unreasonable of me to think it should work this way (what way should it
work... exactly)?


> > Perhaps a more realistic exmaple?:
> > 
> >   class Secure(object):
> >     def __init__(self, name):
> >       self.name = name
> >   
> >     def __getattr__(self, attr):
> >       return getSecureMethod(self.name, attr, getUserPrivileges())
> >         
> >   class LogFoo(Secure):
> >     def __init__(self):
> >       Secure.__init__(self, 'SalaryDB')
> >       
> >     def foo(self):
> >       print 'calling foo'
> >       return super(LogFoo, self).foo()
> >       
> >   lf = LogFoo()
> >   print lf.foo()
> 
> Sorry, I don't get it.  How is this related to metaclasses...?

Not terribly obvious was it... :-)  And it's a bad example too. The
thinking was that if Super's metaclass could intercept special methods
through it's __getattr__, the object returned from super() could look
more like a regular object.  That Super.__getattr__ doesn't check for a
__getattr__ in the __mro__ chain is a problem, but a separate one (sorry
for the confustion).

-- bjorn