RE: [PyCrust] Attribute list hook

[Patrick K. O'B. <po...@or...>]

I'd like to bring this to something of a resolution. The bottom line is that
I folded under the weight of Kevin and Neil's arguments and implemented this
feature as they conceived it. Everyone should be happy with the result, as
the feature is pretty sweet inside PythonCard. Feel free to check out the
latest from cvs.

For the record, I don't think I did a very good job explaining my idea of
how to extend this to make the hook even more flexible. At the same time, my
way would have resulted in a lot more code and a lot more indirection. Kevin
and Neil's way is definitely shorter and cleaner.

However, I still have some reservations. I'm still a little uncomfortable
calling object._getAttributeNames() when there is a chance that some object
may have that very method but use it for something completely different. I
know it is unlikely, but I'd like to see it made even more unlikely.

Now, it seems to me that we can't be the only ones to have faced this
challenge. We have objects with attributes that aren't exposed through the
normal Python conventions, but we would like them to be. That raises the
question of whether Python itself should change. Python keeps track of
object attributes in object.__dict__, object.__methods__, and
object.__members___. The dir() function exposes these attributes. So it
seems to me that it might be nice if Python were extended to allow the dir()
function to also expose magic attributes that the object wanted exposed.
Perhaps there would then be an object.__magic__ attribute for these and a
standard way for the object to "expose" itself for introspection purposes.
If that were the case, shells like PyCrust, PythonWin, Wing, etc. wouldn't
have to change at all to get these magic attributes because dir(object)
would expose them.

How does that strike you folks? Anyone want to write an "Extended
Introspection PEP?"

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Neil Hodgson
Sent: Sunday, August 12, 2001 6:29 PM
To: pyc...@li...
Subject: Re: [PyCrust] Attribute list hook

Patrick K. O'Brien:

> Rather than adopt a naming convention inside of PythonWin or PyCrust, how
> about adding a function as a parameter to our "getAttributes" functions?
So
> PyCrust would look something like:

   Making it a method has the advantage that each class can redefine how
this action is to be performed. For PythonCard we introspect the method
names, for COM the _prop_map_get_ and _prop_map_put_ can be examined, and
for a database the schema can be examined.

   This should be a convention so that it can be implemented independently
by any library author rather than depending on the shell application knowing
about particular libraries.

   If you want to parameterise PyCrust to avoid it knowing about the hook
then that is fine, but applications embedding PyCrust will then typically
instantiate PyCrust with exactly the same dynamic attribute discovery
function.

> pat_orbtech: Here is what I mean. In another project, say Boa for
> example, _getAttributes might mean something entirely different
> than how PythonCard defines it.

   My original name was "getAttributeNames" which is less likely to already
be in use. If really necessary it can get the double underscore and a PEP to
say how it must be implemented if it is implemented.

> Or, Boa may have a method with a different name that returns the
> list of attributes. I'd like to have the flexibility to allow for these
> situations, rather than hardcode in an attempt to do
object._getAttributes.

   Under this scheme, a class has to know about Boa (and PythonWin and Wing
and ...) to expose its dynamic attributes. Or modify Boa to know about the
class or library.

   Neil


_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users