[Python-Dev] Meta-reflections

[Moore, Paul]

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

It seems relevant to me that your choice of name ("attrs") indicates a
relationship with attributes - which your ideas seem to deny. It is
important to make the distinction entirely clear, otherwise your points are
going to get obscured. I've been having a hard time keeping track of
precisely what you are suggesting (on which basis, thanks for this
summary...)

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

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.

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

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.

I'm more or less happy with dir() as a start, although I agree that a better
formal reflection API would be helpful. I suspect that such a thing could be
built in Python on top of the existing facilities, however...

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

I think I agree here. However, if you want slots to behave like normal
attributes, except for the flat namespace, I see no value. Why have the
exception at all?

Hmm, this raises the question of why we have slots at all. If they act
exactly like attributes, why have them? As a user, I perceive them as an
efficiency thing - they save the memory associated with a dictionary, and
are probably faster as well. There can be tradeoffs which you pay for that
efficiency, but that's all. No semantic difference. Actually, that's pretty
much how the descrintro document describes slots. Strange that...

I guess I am saying that I'm happy with slots as designed (documented in
descrintro) - modulo some implementation bugs such as not getting
automatically pickled.

Paul.