'_stringify' tries to convert a unicode string 
into a pure ascii string by 'str(string)'. 
 
This can lead to catastrophic behaviour when 
Python's "defaultencoding" is not "ascii". 
 
The attached patch uses "string.encode('ascii')" 
instead 
to become independent of the default encoding. 
 

Logged In: YES 
user_id=3066

Fixed for Python 2.4.1 and 2.5:

Lib/xmlrpclib.py  1.36.2.1, 1.40
Lib/test/test_xmlrpc.py  1.5.4.1, 1.7

I committed the attached patch and added a unit test. 
Python 2.3 got left out since this doesn't seem critical
enough to destabilize old applications.  I won't strongly
object if someone backports it to 2.3.6, if they actually
think there's going to be a 2.3.6.

Logged In: YES 
user_id=38376

(footnote: like any other global interpreter setting, changing 
the default encoding is a bad idea in general.   the 
setdefaultencoding hook was added for experimentation 
during unicode development, and the idea was to remove it 
when things had settled down.  too bad the documentation 
doesn't reflect this, though...).

Logged In: YES 
user_id=3066

Agreed.  It's use in the test was simply to duplicate the 
environment the xmlrpclib code failed in. 
 
Getting all the right people to agree that it should be 
completely removed and the default encoding always set to 
ASCII is a separate issue, though.  This bug was a 
consequence of the existing, documented flexibility.  As 
long as that exists, the standard library has to deal with 
it. 
 

Logged In: YES 
user_id=38376

Adding a brief "avoid, if possible; may break external libraries, 
may go away in the future; use encoded streams and explicit 
encodings instead" note to the "sys" documentation might be 
a good idea, though.

Logged In: YES 
user_id=38388

+1 on the comment "avoid, if possible; may break external
libraries; use encoded streams and explicit encodings instead".

The "may go away in the future" is not true and, as far as I
remember, was never taken into consideration (remember that
we even wanted the default encoding to be determined by the
locale at one point, but then quickly dropped that idea
again... there's still code in site.py that enables this).
Setting the default encoding to something other than ASCII
is only possible  in site.py and sitecustomize.py - for a
good reason. The site maintainer should be able to use a
different default if needed for whatever reason.

OTOH, libraries should not assume the ASCII setting of the
default encoding and always make their assumption explicit :-)

Logged In: YES 
user_id=38376

"may go away in the future" is definitely true, if you consider 
Python rather than just the CPython implementation.  the 
whole concept of globally configurable conversion rules may 
not make any sense at all in a revised string model...

(and afaicr, dropping the set function was discussed.  don't 
recall in what forum, though, and have no time to go looking 
for it.)