Introspect data from Python missing return parameters

[Tako Schotanus]

The job of the caller? Then why have types at all, why not have every 
method just take a v parameter and be done with it? ;-)

I agree that because DBus is bound to be used with a lot of weakly typed 
languages assuming v would be logical but on the other hand that would 
maybe make it necessary to have have an explicit way of saying that a 
method has no return value. Or should we just live with  every method at 
least returning v, even in strongly typed languages?

I also think it would be worthwhile to stimulate people to make their 
introspection data as complete and correct as possible otherwise lazy 
programmers will just leave it out and we would lose a host of 
interesting possibilities with respect to auto-generated apis, discovery 
tools and who knows what. (Personally I'd make introspection data 
mandatory ;-)

Cheers,
 -Tako

John (J5) Palmieri wrote:

>In Python you can't know what will be returned if anything.  Sanity
>checking returns I feel is the job of the caller.  If anything I would
>just assume return a v which you wouldn't be able to sanity check
>anyway.  
>
>On Thu, 2005-10-06 at 20:14 +0100, Daniel P. Berrange wrote:
>  
>
>>I've been doing some interoperability testing of the Perl bindings, and 
>>noticed a problem with the introspection data returned by Python services.
>>While it provides information about the input parameters on methods, it
>>omits information about the return parameters. Taking the 'example-service.py' 
>>program, it returns
>>
>><!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" 
>>  "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
>><node name="/SomeObject">
>>  <interface name="org.freedesktop.DBus.Introspectable">
>>    <method name="Introspect">
>>    </method>
>>  </interface>
>>  <interface name="org.designfu.SampleInterface">
>>    <method name="GetDict">
>>    </method>
>>    <method name="HelloWorld">
>>      <arg name="hello_message" type="v" />
>>    </method>
>>    <method name="GetTuple">
>>    </method>
>>  </interface>
>></node>
>>
>>Which is basically saying all its methods have no return value. In the Perl
>>bindings I had assumed that introspection data is basically complete, or
>>absent altogether. If present, I use the introspection data for return types
>>to sanity the method reply contents. Hence with the return types missing, 
>>the sanity checks abort the caller. 
>>
>>I expect to receive something closer to:
>>
>><!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
>>  "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
>><node name="/SomeObject">
>>  <interface name="org.freedesktop.DBus.Introspectable">
>>    <method name="Introspect">
>>      <arg type="s" direction="out"/>
>>    </method>
>>  </interface>
>>  <interface name="org.designfu.SampleInterface">
>>    <method name="GetDict">
>>      <arg type="a{ss}" direction="out"/>
>>    </method>
>>    <method name="GetTuple">
>>      <arg type="(ss)" direction="out"/>
>>    </method>
>>    <method name="HelloWorld">
>>      <arg type="s" direction="in"/>
>>      <arg type="as" direction="out"/>
>>    </method>
>>  </interface>
>></node>
>>
>>
>>For weakly typed languages this isn't really too critical whether the
>>return types are there or not, but strongly typed languages which 
>>use introspection data to auto generate API bindings would be handicapped. 
>>Thus I think it would be useful to fill out the spec on introspection
>>to make it explicit about the semantics of the data provided. 
>>
>> * Is it compulsory to list all interfaces ?
>> * Is it compulsory to list all methods/signals within an interface ? 
>> * Is it compulsory to list all parameters/return types for a method ?
>>
>>Personally I'd like the answer to be yes for all of those questions,
>>since it makes it possible to sanity check usage in the client code
>>to provide explicit & informative error messages to the programmer.
>>
>>Regards,
>>Dan.
>>_______________________________________________
>>dbus mailing list
>>dbus at lists.freedesktop.org
>>http://lists.freedesktop.org/mailman/listinfo/dbus
>>    
>>