Class introspection and dynamically determining function arguments

[Bengt Richter]

On Fri, 21 Jan 2005 20:23:58 -0500, "Mike C. Fletcher" <mcfletch at rogers.com> wrote:

>
>>On Thu, 20 Jan 2005 11:24:12 -0000, "Mark English" <Mark.English at liffe.com> wrote:
>>
>>  
>>
>>>I'd like to write a Tkinter app which, given a class, pops up a
>>>window(s) with fields for each "attribute" of that class. The user could
>>>enter values for the attributes and on closing the window would be
>>>returned an instance of the class. The actual application I'm interested
>>>in writing would either have simple type attributes (int, string, etc.),
>>>or attributes using types already defined in a c-extension, although I'd
>>>prefer not to restrict the functionality to these requirements.
>>>    
>>>
>Hmm, I missed the original post, but I'll jump in anyway:
>
>    This sounds a heck of a lot like a property-editing system.  When
>    creating a property-modeled system, the best approach is normally to
>    use something that actually models the properties, rather than
>    trying to guess at the metadata involved by poking around in an
>    arbitrarily structured object.
I agree that "poking around in an arbitrarily structured object" is not
a likely road to satisfaction, but sometimes the arbitrary can be taken out
an something pretty simple can be done ;-)

OTOH, I probably should have mentioned that there are ways to view these
kinds of problems from a longer perspective. E.g., I googled for
"model view controller" and found a nice wiki page at

    http://wact.sourceforge.net/index.php/ModelViewController

that may be worth reading for the OP, just for ideas. There is interesting discussion
of many MVC-related issues, but I don't know anything about the associated project.

>
>    My BasicProperty system allows for this kind of interaction
>    (property-sheets) using wxPython (rather than Tkinter) when using
>    wxoo.  You declare classes as having a set of data-properties (which
>    can have defaults or not, constraints or not, restricted data-types
>    or not, friendly names or not, documentation or not).  Normally you
>    create these classes as subclasses of a class that knows how to
>    automatically assign __init__ parameters to properties, and knows
>    how to tell (e.g.) wxoo about the properties of the class.
Does the BasicProperty base class effectively register itself as an observer
of subclass properties and automatically update widgets etc., a la Delphi
data-driven visual components? I've thought of doing a light-weight form
extension class that would use a text (maybe CSV) definition to control
contruction, and easy programmatic manipulation by python of the definition
parameters, like a stripped-down version of the text view of Delphi forms.
It could also be done via Tkinter, to prototype it. It would be interesting
to allow dragging widgets and edges around in Tkinter and round-trip the parameter
changes automatically into the text representation. A little (well, ok, a fair amount ;-)
further and you'd have a drag-n-drop GUI design tool. But don't hold your breath ;-)

>
>    Those same property classes also allow for editing properties of
>    database rows in PyTable, but that isn't likely relevant to your
>    case.  We've also used them internally to create a rather large
>    web-based property-editing mechanism (applied to such databases),
>    but again, not really relevant to the case at hand.
Who knows, the OP may only be revealing his concerns about a small part of
his great tapestry ;-)

>
>Anyway, if you aren't interested in BasicProperty for this task; another 
>project on which I work, PyDispatcher provides fairly robust mechanism 
>(called robustApply) for providing a set of possible arguments and using 
>inspect to pick out which names match the parameters for a function in 
>order to pass them in to the function/method/callable object.  That 
>said, doing this for __init__'s with attribute values from an object's 
>dictionary doesn't really seem like the proper way to approach the problem.
Sounds like a workaround for parameter passing that maybe should have been
keyword-based?

Regards,
Bengt Richter