[Python-Dev] Meta-reflections

[john coppola]

[ 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
attributes?

class A:
   __slots__=('foo','bar')

class B(A):
   __slots__=('foo','spam')

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
attributes.

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
http://sports.yahoo.com