Hi.
I just did a quick test with suds, and it didn't behave as it did
for Jurko
>>> from suds.client import Client
>>> c =
Client(url='http://ws-server-test.bookingcenter.com/hotel_availabilit...
>>> pos =
c.factory.create('import0:OTA_HotalAvailCalendarRQ.parameters.POS')
No handlers could be found for logger "suds.resolver"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "suds/client.py", line 234, in create
raise TypeNotFound(name)
suds.TypeNotFound: Type not found:
'import0:OTA_HotalAvailCalendarRQ.parameters.POS'
>>> suds.__version__
'0.4'
It should be easy enough to debug the issue with regular suds as well.
Just add a debugger call (import pdb;pdb.set_trace()) before the
factory.create() call and run the steps from there (h for help, s for
step into, n for step over).
The place where suds attempts to resolve the reference you gave it
should be only a few function calls deep. If the relevant code matches
the one in suds-jurko it should be in the BlindQuery.execute() function
in suds/xsd/query.py.
There you can see what exactly it is attempting to find (the fully
qualified reference) and what it actually has in its elements & types
collections.
One thing that might affect this is that the WSDL in question seems
to have different target namespaces for the whole WSDL and for its
schema element. That might be confusing the original suds. I vaguely
recall fixing some such multiple-namespace related issues. There should
be tests for that in the suds-jurko fork.
Best regards,
Jurko Gospodnetić