[Python-Dev] Meta-reflections

[Samuele Pedroni]

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.