Question about accessing class-attributes.

[Bjorn Pettersen]

> From: Michele Simionato [mailto:mis6 at pitt.edu] 
> 
> Bjorn Pettersen wrote:
> 
> > <snip objections against the concept of superclass>
> > > 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__?>..
> 
> Because super(A,C).__class__ returns the class of the super object,
> <type 'super'> not the superclass of A with respect to the MRO of C !

Which is a pure implementation detail (which is why I'd rather not
discuss implementation when we can't even agree on design). If your
superclass  "returns the superclass of A ...", and super(A,C) is the
"super object" representing the context for calling a super method, why
wouldn't it make more sense for super(A,C).__class__ == superclass(A,C)?
(A.k.a., give an example where the current definition of
super(A,C).__class__ is useful, personally it's caused me mounds of
grief <wink>).

[.. exmple indicating singular superclass is insufficient ..]

> > 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.
> 
> Okay, I see your point now, and I give up. 

:-)

[.. reference to super_context in a previous post ..]

> > ..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)
> 
> Right. .If you look at the implementation of Super I posted some time
> ago (in another thread, I think), you will see that  it is not very
> dissimilar. This is a case were I had a working code but a wrong (or
> at least, useless) concept of superclass in mind: you see the
> difference between  theory and practice! ;)

architecture/construction, concept/implementation, design/code, ... :-)

> > [..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?)
> 
> I am not familiar with "semantic analysis" 

It's basically a fancy term for the "design" phase of language design
and, given an existing language, the analysis of what a particular
construct _means_ (this is the semantic part) in a particular context.
E.g. what happens to memory when the program contains "f(x)"? What is
the real (as opposed to visible) structure of the value created when
saying "class X:..."? Given "a.b", which rules define how b is found
(assuming it means attribute lookup)?

The analysis part is done in the "regular way". Start with a set of
atomic operations (axioms), provide formulaes building on these until
you can give formulaes for the constructs in a language (which end you
start at depends on the problem). If the formulaes are internally
consistent (i.e. any construct has exactly one meaning which is well
defined), you have an language that can be implemented as intended (as
opposed to "almost there, just need to hack around this special case").
This entire creation together defines what it means to run a specific
program written in your language (i.e. the language's semantics).  So it
boils down to the creation of a pretty regular logic system, which, as
usual, is as sound as your axioms and your proofs :-)

> (I  can read the BNF and write down the simplest production 
> rules, but that' all).

Which is important. The point that most people (including me) miss the
first time around (especially coming from languages where classes aren't
considered objects), is that if we've defined OBJECT(...) to be the only
atomic operation creating a, let's call it, "compound value", then at
runtime "class X:..." must somehow boil down to OBJECT(..). The simpler
your definition of your atomic operations, the easier it is to create an
implementation for the language (in general).

The theory was originally defined by Plotkin in "A structural approach
to operational semanticts", 1981. If this interest you, see the first
three chapters of http://adam.wins.uva.nl/~x/sos/sos.pdf for an
introduction and references.

> It seems to me quite different from theoretical physics and the 
> branches of mathematics I am familiar with. And even in theoretical 
> physics, you cannot believe *any* theory without experiments. 

Mea culpa. I was confusing theorems vs. theories vs. hypotheses.

> Strictly speaking, you cannot believe even when you have the 
> experiments ;). You can formulate the theory without experiments,
> that's true, but you are never sure that the theory you formulated 
> is fully consistent, even at the pure mathematical level (I have 
> worked on these issues during my Ph.D., therefore I speak for 
> experience). 

Very true. Which is why even language theorists take the time to create
implmentations :-)

> The only thing you can say is that some theories are so obviously
> stupid that you don't need any experiment to refute them ;)

Yet, their proponents are often very adamant <wink>.

It's generally much more time efficient to discover whether something is
correct and consitent by discussing it in the abstract first, instead of
trying to tweak an implementation based on false assumptions to do the
right thing (which, I admit, you can do most of the time, but I would
never call the result aesthetically pleasing :-)

-- bjorn