Python bindings feature complete
John (J5) Palmieri
johnp at redhat.com
Fri Feb 11 12:17:59 PST 2005
I just checked in the rest of my changes to the python bindings. While
they are pretty much feature complete there are some little things that
* Some of the old nomenclature like "service" remain. I want to go
through and fix this where possible causing further breakage and making
grown men cry.
* Recursive types are stuck with restrictions of the C api such as all
array and dict elements must be of the same type. While I could have
made the bindings use variants everywhere this would make using python
to call into C services impossible. Once introspection is implemented
this should not be an issue.
* Introspection - anyone what to help with this?
* Optimizing signature creation. Right now when we need to get a
signature of a container's children we recurse all the children. This
is done each time we need the signature, whether or not we have
traversed the children already for a higher level container. For
example a data structure of signature aaai would recurse three times:
We should only recurse once (aai) and then use the results to generate
the other two signatures (ai, i).
Changes to signal handling:
Signal handlers used to have a fixed length parameter list:
def signal_handler (interface, signal_name, service, path, message)
These parameters are now consolidated into a single Sender object so
signal handlers now look like:
def signal_handler (sender)
On top of that, by default all message arguments are expanded into the
signal handler's parameter list which provides better documentation and
a clearer picture of what is being sent by the signal:
def signal_handler (sender, arg1, arg2, etc)
In order to work with some applications which send variable length
parameter lists instead of sending a list as one of the parameters
(*cough*Hal*cough*) there is an option for not expanding the arguments
when triggering the signal callback. One can set this when registering
the signal handler:
As I said earlier by default we expand the arguments.
John (J5) Palmieri
Associate Software Engineer
Red Hat, Inc.
More information about the dbus