[Python-Dev] Meta-reflections (original) (raw)

Kevin Jacobs jacobs@penguin.theopalgroup.com
Mon, 18 Feb 2002 14:33:04 -0500 (EST)

On Mon, 18 Feb 2002, David Ascher wrote:

I think that you're making useful points, but I think that it's worth stepping even further back and deciding what the reflection API should be like from a "what's it for" POV?

Exactly! However, having a meta-discussion on meta-reflection is a little too abstract for the disinterested to jump in on. However most people who read python-dev use and come to rely on using dict as The Python Reflection API for instance attributes.

This relates to much of the discussion about what dir() should do on new-style classes, as well as why some Python objects have 'members', some have 'methods', etc.

Sure, except that I've NEVER assumed dir() was anything more than a quick-and-dirty ultra-high level hack that was occaisonally useful for doing reflection. One call does not a reflection API make.

In my opinon, dict is mostly an implementation detail, and it makes sense to me that the slot names dont' show up in there (after all, it's not a dictionary!).

I think so too, though I don't want to ram my own views down people's throats on the matter. However, it is potentially valid to view dict as the one true reflection API for getting access to all attributes. This isn't too outlandish since it effectively is in Python 2.2. Pickle and cPickle 2.2 (among several dozen other examples I've found) are currently implemented assuming this. If we wanted to keep this existing API we could support reflection on slots by extending object instances with only slot attributes to share a common read-only dict. New style class instances with per-instance dict's should start with a mutable copy when instantiated. For the record, I don't think this is the right way to go, even though it is a valid way way of defining the Python reflection API.

What I'd propose is that the inspect module grow some "abstract" reflection APIs which make it possible for folks who don't need to know about implementation details to get away with it.

Great idea! I've already got a stack of suggestions and patches that clean up other various bits of it.

However, there was an unstated and important question left out of my last e-mail: We need to decide if slots are really 'attributes' or "something else". The "something else" being akin to set/getattr virtual attributes, pure properties, and other techniques that will almost always require explicit hooks to into reflection APIs. My preference is the former, that slot declarations simply affect the allocation choices made by an object, and not the semantics of what may be done with that object (modulo issues when per-instance dicts are not allocated).

Thanks, -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