Question about accessing class-attributes.

[Michele Simionato]

Bjorn Pettersen wrote:
> > Let's say I do:
> > 
> >   sc = superclass(C,S)
> > 
> > what can I do with sc? Specifically,
> > 
> >   sc.a != super(C,S).a
>because sc.a is an unbound attribute of the class sc or a bound
>attribute of sc.__metaclass__, while super(C,S).a is a bound method
>created from the first implementation in S.__mro__[index(C}+1:], which
>could potentially be sc but only as a special case, and S. There really
>isn't any equivalence

Not in a strict sense, yes, but look at what I said:

>If super had a __superclass__ attribute I could say to the newbie
>
>super(A,C).a <=> super(A,C).__superclass__.a <=> B.a 
>
>Of course, the equivalence would not be exact in subtle cases,
>i.e. when B does not have an 'a' attribute, nor it inherits it,
>but it has (or inherits) a __getattr__ defining 'a' (as Bjorn 
>pointed out)
>Still in the typical case there would be equivalence. 

This is the typical case I had in mind (I am thinking about attributes,
not about methods)

def superclass(C,S):
        mro=list(S.__mro__)
        return mro[mro.index(C)+1] 

class A(object): a=1
class B(object): a=2
assert super(A,C).a is superclass(A,C).a # okay
assert super(A,C) is B.a # okay

These are the tricky cases I am aware of, where there is no equivalence
(speaking for attributes only):

#tricky case #1

class A(object): a=2
class B(object):
    class __metaclass__(type):
        a=2

class C(A,B): pass

assert B.a is superclass(A,C).a # okay
super(A,C).a # attribute error


#tricky case #2

class A(object): a=2
class B(object):
    class __metaclass__(type):
        def __getattr__(cls,name):
            if name=='a': return 2

class C(A,B): pass

assert B.a is superclass(A,C).a #okay
super(A,C).a # attribute error

In my view, one could say that for most uses super(A,C) can be seen as
a proxy to the methods of superclass(A,C)==B, and that the exceptions are
in rather special and advanced cases. But the fact that those case are special
and quite advanced is only a personal opinion, of course ;)

> It is simply that I can run actual code and experiment with it,
> I can try some test cases, etc. I cannot do that with pseudo-code.
> Often ideas that works on paper don't work in reality :-(

>Similarly you can run pseudo code, except you have to think about the
>process instead of relying on the answer a specific implementation gives
>you. 

I disagree, you cannot run pseudo-code in your mind and believe that
it will run the same in the real word. But perhaps your mind is a
much better compiler than mine ;)

>What I'm talking about is language theory, i.e. how things are
>_supposed_ to work or a concreate description of how something _does_
>work. Arguing about details of a concrete implementation is both
>fruitless (I don't care how it works, I want to know how it should
>work), and time-consuming (to get anything runnable you'd have to
>implement _at_least_ and abstract syntax tree evaluator, and you'd have
>to get the ast's from somewhere... and it'd have to be for a large
>enough subset of the language that it was interesting).
>If you can't get the theory to hang together "on paper" first, you're
>going to end up hacking an endless series of special cases in your
>implementation -- with the result simply being a different implmentation
>with no more insight into how things should work than the origianl
>implementation.

We have different philosophies, then. Whereas I am a theoretical
physicists and I have also worked in mathematical physics and pretty
abstract stuff, when it comes to programming I am an eminently *practical*
person. I *never* start top-down, writing my design on the paper: I always
begin coding with a very little idea of what I want to do. It is the practical
implementation and experimentation that drives me to the final result, which
is necessarely always different from what I had in mind in the beginning.
I code *first*, put things on the paper later, when I have a working
implementation. That's why Python dynamism and rapid development
times fit my mind so well.

Cheers,

                                           Michele