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.
participants (4)
-
Fred L. Drake, Jr.
-
Kevin Jacobs
-
martin@v.loewis.de
-
Moore, Paul