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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4