[Python-Dev] Meta-reflections

[Kevin Jacobs]

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.  In virtually all other ways I expect them to act like
attributes.  The question is should the static allocation introduce all the
complex scoping rules that come with Java fields or C++ instance variables.
If we go by the "principle of least surprise", it seems much better to keep
the normal Python attribute rules than those of Java or C++.

> > > Given that implementing slots with fields is one of the possibility for
> > > Jython
> >
> > This is possible for flat slot namespaces too; just remap new slots to
> > existing ones when they overlap, instead of allocating a new one.
>
> Yes, but from the POV of fields this is less natural.
> There's a trade-off issue here.

Less natural for Java maybe, but not 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'.

> 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_.
So, in virtually all respects, Jython 2.2 could ignore their existence
totally and still function correctly.  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.

> 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.

Best regards,
-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com