[Fedora-suds-list] print client does not show types of results of methods

Matt C mcauthorn at gmail.com
Tue Nov 3 21:57:50 UTC 2009


This may or may not be the best way to do this, but I've been digging
around for this type of information as well and came up with some
useful information here (for my particular WSDLs):

method = c.sd[0].ports[0][0].method('get_list')

In [15]: method.soap.input
Out[15]:
(Input){
   body =
      (Body){
         parts[] = <empty>
         use = "encoded"
         namespace[] =
            "b0",
            "urn:iControl:LocalLB/VirtualServer",
         wrapped = False
      }
   headers[] = <empty>
 }

-- and --

In [16]: method.soap.output
Out[16]:
(Output){
   body =
      (Body){
         parts[] =
            (Part){
               root = <part type="tns:Common.StringSequence" name="return"/>
               name = "return"
               qname[] =
                  "return",
                  "urn:iControl",
               element = "None"
               type = "(u'Common.StringSequence', urn:iControl)"
            },
         use = "literal"
         namespace[] =
            "tns",
            "urn:iControl",
         wrapped = False
      }
   headers[] = <empty>
 }

Which allows for stuff like:

In [19]: for x in method.soap.output.body.parts:
   ....:     print x.name, x.type
   ....:
   ....:
return (u'Common.StringSequence', urn:iControl)

This may or may not be useful for you here, but in the event it saves
someone some cycles I wanted to put this out to the list. I found this
a handy way to inspect input/output for a particular method.

-Matt

On Tue, Nov 3, 2009 at 11:18 AM, Jeff Ortel <jortel at redhat.com> wrote:
>
>
> On 11/03/2009 08:05 AM, Rod Montgomery wrote:
>>
>>  From browsing the Suds source code, I get the impression that Suds does
>> not even use the type info specified in the WSDL files for the results
>> of methods. It just parses whatever XML comes back from the service,
>> converts it to a corresponding Pythonic data structure, and returns that.
>
> That's not correct.  Suds does match the method's returned type with that
> declared in the WSDL.  There are two reasons for this.  First, it validates
> that what is returned matches the schema.  Second, it uses this information
> to convert types between XML to the correct python objects.  For example,
> xs:int converted to a python integer.
>
>>
>> I guess that's ok, except that it means that, to understand what comes
>> back, I have to dig through the WSDL files.
>
> [1]. I agree.  A good enhancement would be for suds to display the return
> types as part of the method signatures displayed when you print the client.
>
>>
>> Do any other SOAP clients -- Pythonic or not -- actually use the
>> WSDL-specified method-result types? For what?
>>
>> For error detection, how useful would it be to have a "result type does
>> not match type declared in WSDL files" exception thrown at the point
>> where the result comes back, rather than maybe have some random
>> no-such-member exception(s) thrown while trying to process the result?
>>
>> How annoying would it be, to have a "result type does not match..."
>> exception thrown, when the mismatch would not have affected the proper
>> operation of the client code anyway?
>>
>> I wonder whether I could make Suds just remember the declared type of
>> each method result, and display it in the "print client" output, purely
>> as human-readable documentation? Maybe just tack another element onto
>> the tuple that represents each method in the .ports member of the
>> suds.servicedefinition.ServiceDefinition class, and pick it up for
>> display in the description member function of that class?
>
> Yes.  See [1] above.
>
>>
>> _______________________________________________
>> fedora-suds-list mailing list
>> fedora-suds-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-suds-list
>
>
> _______________________________________________
> fedora-suds-list mailing list
> fedora-suds-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-suds-list
>




More information about the suds mailing list