Upgrading standard library module

[Bryan]

On Feb 13, 1:52 pm, Jason Scheirer <jason.schei... at gmail.com> wrote:
> On Feb 13, 12:42 pm, Bryan <bryanv... at gmail.com> wrote:
>
> > I have a Python v2.5.2 server running and I found some undesirable
> > behavior in the xmlrpclib module that is included with that version of
> > Python.  The xmlrpclib version that is included with Python 2.6
> > changes the behavior for the better.  I nervous about upgrading my
> > Python install to 2.6 on this server because I remember reading in the
> > docs of a library I use that it targets the 2.5 branch.  What is the
> > best way to only upgrade the xmlrpclib in my 2.5 install?
>
> > Also, have you all had problems with libraries not specifying which
> > Python version they target?  I can't find a requirements for the
> > formencode library.  It is kind of scary upgrading my Python server
> > install without being sure all my libraries will work.  Experiences??
>
> > Bryan
>
> Python has always been pretty backwards-compatible and has a nice
> roadmap for upgrades (with new languages features living in __future__
> for a version or so before they're in the main version). With the
> exception of 2.X->3, you can usually assume that any pure-Python
> modules written for 2.x will work in 2.(x+1), and assuming they don't
> issue any warnings, also in 2.(x+2).
>
> What behavior, exactly, do you not like in xmlrpclib? Diffing the 2.5
> and 2.6, only significant differences I see are checks for True/False
> as builtins left over from pre-2.4 and some datetime handling.

The xmlrpclib in my 2.5.2 install does not allow the marshaling of my
custom objects.  It checks the type of my object, and if it isn't in a
hard-coded list of types, then a "Cannot marshal object of <type>
type" exception message shows up.  The version in my Windows 2.6
install has a fall back case where if the type is not in the hard-
coded list, it simply calls Object.__dict__ to get a graph of the
object's values that can be marshaled into xmlrpc.

I am using xmlrpc through Pylons.  As a workaround, instead of
returning my custom objects in my xmlrpc server functions, I return
MyObject.__dict__

I also did not see anything in the revision log in the source file
about this change.