[ 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4