[Python-Dev] Meta-reflections

john coppola john_coppola_r_s@yahoo.com
Mon, 18 Feb 2002 12:01:17 -0800 (PST)

[ David Ascher <DavidA@ActiveState.com> 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?
> 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. 

I think his points were more than useful.  His
examples expose serious flaws with the use of slots,
which I hardly see as satisfactory behavior. 
Particularly, are slot attributes to be treated like
MRO or not?  Hummm...

Does each class have a separate set of slot

class A:

class B(A):

What are we supposed to expect here?

I believe things would be greatly simplified if the
inheritance tree was traversed and all slot attributes
were concatenated and regarded as unique for a given
instance.  So in the above example we would expect
(breadth first then depth),
__slots__ =('foo', 'spam', 'bar').

A note on dir...
Since we have no other introspection tools aside from
dir, I as of this revision of python dir should
correctly display slot attributes with dict

Does "dir" stand for directory or does it mean
__dict__.keys()?  I believe this is an implementation
detail.  Dir should lookup every attribute, but now we
need two additional functions: slotdir(), dictdir(). 
Maybe better names: slots(), dictdir().
Another argument for why dir should be changed, is
that cPickle and pickle would problably function
correctly as a result of changing dir's implementation
to reveal slot attributes.

But even on another note which digs deeper into the
philosophy of __slots__, why not use slots for class
methods?  Can this already be done?  It can be used
everywhere, modules, imported modules, classes,
instances, etc.


> In my opinion, __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!).  
> 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.
> Looking at it, maybe it already has everything we
> need.  I'm not quite
> sure why inspect.getmembers is called that, but
> maybe I'm the only one
> who's not sure what 'members' mean in Python.
> --david
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev

Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games