Re: [PyCrust] Attribute list hook

[Neil H. <ne...@sc...>]

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