[Python-Dev] Meta-reflections

[Kevin Jacobs]

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