[Python-Dev] Meta-reflections

[Kevin Jacobs]

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