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.