Re: [Python-Dev] Meta-reflections
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.
participants (4)
-
David Ascher
-
Gordon McMillan
-
Kevin Jacobs
-
Moore, Paul