[Python-Dev] Meta-reflections (original) (raw)

Samuele Pedroni pedroni@inf.ethz.ch
Tue, 19 Feb 2002 23:23:05 +0100

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.