[Python-Dev] Meta-reflections

[Moore, Paul]

From: Kevin Jacobs [mailto:jacobs@penguin.theopalgroup.com]
> > FWIW, I disagree with this completely. I would expect
> > slots with a particular name in derived classes to hide
> > the same-named slots in base classes. Whether or not the
> > base class slot is available via some sort of "super"
> > shenannigans is less relevant. But hiding semantics
> > is critical. How do you expect to reliably make it
> > possible to derive from a class with slots otherwise?
> > Perl gets into this sort of mess with its implementation
> > of objects.
>
> Attributes currently have a flat namespace, and the
> construct that I feel is most natural would maintain that
> characteristic. e.g.:

Oops. Sorry, I got that completely wrong. OK, I side with silent re-use.
That's what attributes do. [Meta-meta comment: the rule should be to work
"just like" attributes.] So why did you feel the need to separate this point
from your point (3)? It gives the impression that this point differs from
attributes, in contrast to the things mentioned in (3).

> > Agreed - up to a point. I don't see a need for a way
> > to distinguish between slots and "normal" attributes,
> > personally. But I don't do anything fancy here, so my
> > experience isn't very indicative.
>
> Without a more formal reflection API, the traditional
> way to get all normal dictionary attributes is by using
> instance.__dict__.keys().

The official, and supported, way is to use dir(). This was hashed out on
python-dev at the time. As I understand it, dir() always "worked", and was
extended to support slots when they were added. __dict__ clearly only
handles dict-based attributes, and so cannot be extended to include slots.
The official advice on reflection was therefore modified to point out that
dir() and __dict__.keys() were no longer equivalent, and dir() was "the way"
to get the full set. (Whether this advice was included into the formal
documentation, I couldn't confirm, but it was written down - arguing "if
it's not in the documentation, it's not official", is a little naive, given
the new and relatively experimental status of the whole area...)

> All I'm proposing is that instance.__slotattrs__ (or
> possibly instance.__class__.__slotattrs__) returns a
> list of objects that reveal the name of all slots in the
> instance (including those declared in base classes).

Do you have any reason why you would need to get a list of only slots, or
only dict-based attributes? Given that I'm arguing that the two should work
exactly the same (apart from storage and efficiency details), it seems
unreasonable to want to make the distinction (unless you're doing something
incestuous and low-level, when you're on your own...)

Remember, instance.__dict__['attrname'] is now regarded as incomplete in the
face of slots. Again, I point you to the descrintro document, just below the
discussion of slots, in the paragraphs starting from "The correct way to get
any attribute from self inside __getattribute__ is to call the base class's
__getattribute__ method".

> The only issue that concerns me is that I am not sure if the 
> slot to slot name mapping should be fixed.

I haven't melted my brain enough to understand the PEPs, but I believe that
there are ways of doing all sorts of low-level hacking with descriptors, if
you really want to. I don't believe that making this easy for "normal" users
is a good thing.

[BTW, this reminds me of your point on what is documented. I believe that
the PEPs and descrintro count as the canonical documentation of these
features. If they haven't been fully migrated into the Python documentation
set yet, that's a secondary issue. The PEPs *are* the definition of what was
agreed - people had time to comment on the PEPs at the time. And the
descrintro document is the current draft of the user-level documentation.
You can assume it will end up in the manuals. That's my view...]

> EXACTLY! I want to use slots (or slotattrs, or whatever
> you call them) to be solely an allocation declaration.
> For small objects that you expect to create many, many
> instance of, they make a huge difference.

In which case, you are giving the impression of wanting large changes, when
you really want things to stay as they are (modulo some relatively
non-controversial (IMHO) bugs). If you read the descrintro document on
slots, you will see that it presents an identical viewpoint. OK, there are
some technical restrictions, which will always apply because of the nature
of the optimisation, but the intention is clear. And it matches yours...

Paul.