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

Kevin Jacobs jacobs@penguin.theopalgroup.com
Tue, 19 Feb 2002 12:23:40 -0500 (EST)

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