From: Kevin Jacobs <jacobs@penguin.theopalgroup.com>
> On Tue, 19 Feb 2002, Samuele Pedroni wrote:
> > Personally I don't expect slots to behave like attributes. I mean,
> > the different naming is a hint.
>
> For me, slot declarations are a hint that certain attributes should be
> allocated 'statically' versus the normal Python 'dynamic' attribute
> allocation.
Interesting but for the implementation:
class f(file):
__slots__ = ('a',)
slot a and file.softspace are in the same league,
which is not attributes' league.
They are struct member and the descriptor
logic to access them exploit this.
>From the implementation it seems clear that slots and attributes
are not interchangeable.
On the other hand that means that there cannot be a slot-only future
for Python.
> > > I'll contend that the current implementation is flawed for this and
several
> > > other reasons I've stated in my previous e-mails. Of course, we're
waiting
> > > to hear back from Guido when he returns, since his opinion is infinitely
> > > more important than mine in this matter.
> >
> > It is not flawed, it is just
single-inheritance-of-struct-like-layout-based.
> > I'm fine with that.
>
> Please read some of my earlier messages. There are other 'warts'.
Yes, but changing the whole impl design is probably not the only solution.
I mean this literally.
> > To be honest I would find very annoying that what we are about
> > to implement in Jython 2.2 should be somehow radically changed for Jython
2.3.
> > We have not the necessary amount of human resources
> > to happily play that kind of game.
>
> Well, we are dealing with an implementation that is not documented _at all_.
The 2.2 type/class unification tutorial has references to __slots__:
http://www.python.org/2.2/descrintro.html
What is true is that the surface aspects of the undelying design are not
documented.
> So, in virtually all respects, Jython 2.2 could ignore their existence
> totally and still function correctly.
False. See above.
> I hope that you will be pleased by
> the in-depth discussions on this topic, since it will likely lead to the
> formulation of refined documentation for many of these very fuzzily defined
> features. As an implementer, that kind of clarification can be invaluable
> since it means you don't have to guess at the semantics and have to change
> it later.
This one is insolent.
Btw the tutorial contain this:
There's no check that prevents you to override an instance variable already
defined by a base class using a __slots__ declaration. If you do that, the
instance variable defined by the base class is inaccessible (except by
retrieving its descriptor directly from the base class; this could be used to
rename it). Doing this renders the meaning of your program undefined; a check
to prevent this may be added in the future.
> > I hope and presume that Guido did know what he was designing,
> > and I had that impression too.
> > OTOH I agree that pickle should work for new-style classes too.
>
> He knew what he was designing, but was focused on achieving other goals with
> this infrastructure (like class/type unification). I have the feeling that
> slots were more of an experiment than anything else. Don't get me wrong --
> they are insanely useful even in their current state. On the other hand, I
> don't think they're ready for prime-time until we smooth over the picky
> semantic issues relating to slot overloading, reflection and renaming. Just
> look at the Python standard library -- you'll notice that slots are not used
> anywhere. I predict that we will be using them extensively, especially in
> the standard library, as soon as they are deemed ready for prime-time.
>
A possible approach:
write a patch implementing your preferred semantics.
You can keep it orthogonal from the rest, using
a name different than "__slots__", for the first
cut.
regards, Samuele Pedroni.
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