I'm porting working implementation from python2 to python3 and a line where I use suds to deserialize XML:
response = self.client.service.myMethod(__inject={ 'reply': responseXml } )
I used to receive an object, but now it throws an exception:
File "/usr/lib/python3.6/site-packages/suds/client.py", line 521, in __call__
return client.invoke(args, kwargs)
File "/usr/lib/python3.6/site-packages/suds/client.py", line 764, in invoke
msg = self.method.binding.input.get_message(self.method, args, kwargs)
File "/usr/lib/python3.6/site-packages/suds/bindings/binding.py", line 109, in get_message
content = self.bodycontent(method, args, kwargs)
File "/usr/lib/python3.6/site-packages/suds/bindings/document.py", line 95, in bodycontent
add_param, self.options().extraArgumentErrors)
File "/usr/lib/python3.6/site-packages/suds/argparser.py", line 83, in parse_args
return arg_parser(args, kwargs, extra_parameter_errors)
File "/usr/lib/python3.6/site-packages/suds/argparser.py", line 109, in __call__
return self.__all_parameters_processed()
File "/usr/lib/python3.6/site-packages/suds/argparser.py", line 146, in __all_parameters_processed
self.__check_for_extra_arguments(args_required, args_allowed)
File "/usr/lib/python3.6/site-packages/suds/argparser.py", line 169, in __check_for_extra_arguments
self.__error(msg % (param_name,))
File "/usr/lib/python3.6/site-packages/suds/argparser.py", line 196, in __error
raise TypeError("%s() %s" % (self.__method_name, message))
TypeError: myMethod() got an unexpected keyword argument '__inject'
Comparing client.py between python2 and python3, it doesn't look much has changed.
Apparently nobody else uses SOAP anymore as this doesn't yield any search engine hits, so I'm posting this here.
Any hints to actual problem are welcome.
So, looks like the whole argument prossing has been rewritten between python2 and python3. CentOS7 where I run this, has Jurko flavor of Suds and it has argparser.py file that processes all arguements. That file did not exist in python2 version of Suds.
Also, the pieces of code that handle simulation __inject part have changed, but they seem to work. It's just the argument processing that fails to understand __inject argument. And that __inject is not present in options.py where it should be. Adding it there manually doesn't fix the problem, I don't know where it actually resides, code is very abstract (probably because SOAP is defined at server side, so it has to be) and I've problems wrapping my thougts around it without spending a lot of hours with this.
Modifying system Suds file, the argparser.py __all_parameters_prosesed() method, my line 146 and commenting out/disabling the call:
will fix not being aware of __inject argument.
I also had to set retxml before calling the __inject method:
I think retxml can be given as an argument like __inject as well. For some unknown reason it has flipped into True with __inject and that function will return early with XML, not the expected deserialized python class instance.
I don't like the solution, it requires changes to the system Suds files. And I think it's broken when it doesn't know its own arguments.