[Python-Dev] Meta-reflections

Samuele Pedroni pedroni@inf.ethz.ch
Tue, 19 Feb 2002 18:29:55 +0100


Hi.

From: Kevin Jacobs <jacobs@penguin.theopalgroup.com>
> On 18 Feb 2002, Martin v. Loewis wrote:
> > Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> > >   2) Should attribute access follow the same resolution order rules as
> > >      methods?
> >
> > Yes, I think so.
> 
> Ouch!  This implies a great deal more than you may be thinking of.  For
> example, do you really want to be able to do this:
> 
>     class Foo(object):
>       __slots__ = ('a',)
> 
>     class Bar(Foo):
>       __slots__ = ('a',)
> 
>     bar = Bar()
>     bar.a = 1
>     super(Bar, bar).a = 2
>     print bar.a
>     > 1
> 
> This violates the traditional Python idiom of having a flat namespace for
> attributes, even in the presence of inheritance.  This has very profound
> implications to Python semantics and performance.
> 

Probably I have not followed the discussion close enough.
The variant with super does not work but

>>> bar=Bar()
>>> bar.a=1
>>> Foo.a.__set__(bar,2)
>>> bar.a
1
>>> Foo.a.__get__(bar)
2
>>>

works. Slots are already not flat.
They have basically a similar behavior to fields
in JVM object model (and I presume in .NET).

Given that implementing slots with fields is
one of the possibility for Jython (and some
possible Python over .NET), with indeed
some practical advantages [Btw for the
moment I don't see obstacles to such an 
approach but I have not considered
all the details], it is probably
reasonable to keep things as they are.

Consider also:

>>> class Goo(object):
...  __slots__ = ('a',)
...
>>> class Bar(Goo,Foo): pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: multiple bases have instance lay-out conflict

that helps and reinforces that model.

Samuele.