[Tutor] immutable objects

[Danny Yoo]

> here is the stack
> trace. i know that SOAPpy is doing wrong by not checking the type of
> the element along with id(ele).
> I thought if there is any work around the problem i could use that without
> upgrading SOAPpy after it is fixed.

Hi Premnath,

You might want to see if some other SOAP module might be better supported. 
The last version of SOAPpy that I've seen appears to have been released in 
2005, and as far as I can tell, the project is languishing a bit.  Most of 
the energy toward Python and SOAP seems to be focused on the Zolera SOAP 
Infrastructure (ZSI) project, which can be found at:

     http://pywebsvcs.sourceforge.net/


Thanks again for the stack trace; it helps pinpoint some problems.  I did 
some quick checks on the stack trace; the line numbers from the stack 
trace aren't matching up with SOAPpy 0.12.0., so I'm not sure if this 
problem has already been fixed or not.  You may want to make sure you have 
the latest release of SOAPpy if you continue using that module.


The code for SOAPBuilder.dump_string() just doesn't look right to me. 
Why does one have to do a checkref() on it when serializing the string 
data, given that a string has no internal structure to speak of?  I think 
the code there is just wrong.  You're seeing this failure simply because 
you're passing in two strings with the same id, which should be perfectly 
legal and fine.  SOAPpy is definitely at fault here.

I kludged up the recursive-checking code on strings (i.e. turned it off), 
and now see the following:

##########################################################################
>>> import SOAPpy
>>> rmt = SOAPpy.SOAPProxy("http://soap.test.com",
...                        header = SOAPpy.Types.headerType(
...                            data = {'username': 'prem',
...                                    'password': 'prem'}))
>>> rmt.testcall()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "SOAPpy/Client.py", line 470, in __call__
     return self.__r_call(*args, **kw)
   File "SOAPpy/Client.py", line 492, in __r_call
     self.__hd, self.__ma)
   File "SOAPpy/Client.py", line 363, in __call
     config = self.config)
   File "SOAPpy/Client.py", line 263, in call
     raise HTTPError(code, msg)
SOAPpy.Errors.HTTPError: <HTTPError 405 Method not allowed>
##########################################################################

which looks a little more promising.


In fact, you can see this yourself by playing a small trick:

#######################################################################
>>> rmt = SOAPpy.SOAPProxy("http://soap.test.com", header = 
SOAPpy.Types.headerType(data={'username': 'p' + 'rem', 'password': 'p' + 
'rem'}))
>>> rmt.testcall()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "SOAPpy/Client.py", line 470, in __call__
     return self.__r_call(*args, **kw)
   File "SOAPpy/Client.py", line 492, in __r_call
     self.__hd, self.__ma)
   File "SOAPpy/Client.py", line 363, in __call
     config = self.config)
   File "SOAPpy/Client.py", line 263, in call
     raise HTTPError(code, msg)
SOAPpy.Errors.HTTPError: <HTTPError 405 Method not allowed>
#######################################################################

Forcing the manual string concatenation lets you go on, but this is just a 
silly kludge around what is fundamentally a bad SOAPYpy bug.


My current recommendation is to try using ZSI instead: the SOAPpy code 
base appears to have a bit of bit rot.


Good luck to you!