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

Kevin Jacobs jacobs@penguin.theopalgroup.com
Wed, 20 Feb 2002 05:45:38 -0500 (EST)

On Tue, 19 Feb 2002, Samuele Pedroni wrote:

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.

Currently this is true, though only you and Martin v. Loewis have replied agreeing that this should be the case. Everyone else I've spoken to wants slots to act more like instance attributes.

Yes, but changing the whole impl design is probably not the only solution. I mean this literally.

I realize this. That's why I'm trying to build a consensus until some sort of clarity emerges. That's also why I'm asking for feedback on what should be the correct semantics of slots instead of assuming that the current implementation is the One True Bible of slots. If you think that slots are implemented correctly, then I welcome you to work with me to make exactly that case. Unless you (or others) step up to do that, I will continue to feel that the current slot implementation is flawed and will continue to advocate their reform. Unfortunately, repeatedly pointing out that my suggestions are not how they are implemented doesn't advance either of our cases.

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

A tutorial is not documentation. It is certainly suggestive of what will eventually be documented, but it is not documented until it is part of the Python Reference Manual. For example, I would not be surprised if large hunks of the descrintro ceases to work after the 'super' and 'property' syntax changes slated for Python 2.3.

> So, in virtually all respects, Jython 2.2 could ignore their existence > totally and still function correctly.

False. See above.

Don't take my word for it -- ask Guido when he gets back.

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

Please, lets not descend into name calling. I truly believe that I am providing a service to the general Python community by engaging in these discussions. If you feel that it is insolent to question the language implementers just because I am a newcomer and have some controversial issues, then I recommend that you rapidly get used to it. I do it all the time and don't plan to stop.

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.

I fully intend to provide a reference implementation of some of these ideas. In fact, its likely to be a fairly small patch. However, I still don't know what the ideal semantics are. I would very much value your input on the matter, even if on a purely theoretical level. So, lets start with the premise that attrs is a declaration like slots except that:

  1. the namespace of these 'attrs' is flat -- repeated names in descendant classes either results in an error or silently re-using the existing slot. This maintains the traditional flat instance namespace of attributes.

  2. A complete and immutable list of slots is available as a member of each type to allow for easy and efficient reflection. (though I am also in favor of working on better formal reflection APIs)

  3. These 'attrs' are to otherwise have the same semantics as normal dict instance attributes. e.g., they should be automatically picklable, they can have properties assigned to them, etc.

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