Question about accessing class-attributes.

Bjorn Pettersen BPettersen at NAREX.com
Sun May 4 00:40:24 EDT 2003


> From: Michele Simionato [mailto:mis6 at pitt.edu] 
> 
> 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:

Well, if they're not strictly equivalent, and with no definition of when
they'd not be equivalent, and only work for attributes, I'm failing to
see what purpose it could serve?

> > If super had a __superclass__ attribute I could say to the newbie
> > super(A,C).a <=> super(A,C).__superclass__.a <=> B.a 

...<aside: why not super(A,C).__class__?>..

[..__getattr__ special case..]

> >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)

I'm not sure why you want to make a difference, but ok. Let me change
your example just a little:

  def superclass(C,S):
     # mro=list(S.__mro__)  let's assume we're dealing with objects
instead
     mro = list(S.__class__.__mro__)
     return mro[mro.index(C)+1] 
 
  class T(object): a = 0	
  class A(T): pass
  class B(T): a = 2
  class C(A,B): a = 3
  c = C()

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

  print super(C,c).a, superclass(C,c).a  # 2 0

The key word here is _cooperative_. A singular superclass has no
meaning, you need the entire list of the remaining superclasses, in the
right order.

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

Could you give definitions instead of examples :-)

> 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 

>From above that's false, it is only true with single inheritance and
special cases of multiple inheritance. In a previous post I defined the
semantics of super (it would be helpful if you come up with something
more precise than "in most cases", e.g. listing when not etc.) by
introducing the concept of a super_context. You can define a working
version of your superclass in terms of that too:

  # new version, fixing obj/class problem
  def super_context(A1, A2):
      if isinstance(A2, A1):
          mro = list(A2.__class__.__mro__)
      else:
          mro = list(A2.__mro__)
      remaining = mro[mro.index(A1)+1:]
      return remaining

  class superclass(object):
      def __init__(self, cls, obj):
         self.__ctxt__ = super_context(cls, obj)

      def __getattr__(self, attr):
         for cls in self.__ctxt__:
             if attr in cls.__dict__:
                 return cls.__dict__[attr]
         raise AttributeError(attr)  

whith this definition you can also do:

  superclass(Cls, obj).__getitem__(obj, key)

[..pseudocode vs working 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.
[...]

But this isn't programming. This is semantic analysis which should be
very similar to theoretical physics (do you need a working experiment to
discuss a theory?)

-- bjorn





More information about the Python-list mailing list