This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Broader iterable support for xmlrpclib
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.2
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: iritkatriel, loewis
Priority: normal Keywords: patch

Created on 2005-12-06 04:14 by skip.montanaro, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
xmliter.diff skip.montanaro, 2007-03-11 01:21 review
Messages (9)
msg49173 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2005-12-06 04:14
The XML-RPC spec supports a fairly limited set of datatypes.
Most languages, Python included, contain many more types
than XML-RPC.  Some types, such as Python's complex number
type, have no reasonable analog in XML-RPC.  Others, such as
unicode objects and array objects do.  This patch allows
anything that can be converted to a list but that is not
otherwise supported directly by the xmlrpclib module already
to be marshalled as an XML-RPC array if the allow_iter
parameter to the ServerProxy constructor evaluated to true.
This includes sets and arrays.


1. Python already overloads the XML-RPC array type with both
   lists and tuples.  This just extends that overloading to
   other currently unsupported Python types which can be
   converted to lists.  Why should lists and tuples have all the

2. Providing transparent conversion to XML-RPC arrays keeps
   calling code a bit cleaner.  One of the attractions of
   XML-RPC is that the remote procedure call looks identical
   to a local call.  This is especially true in Python
   because of /F's excellent little _Method class.  Clearly
   as a programmer I could type:

       import array
       a = array.array('i', [1, 2,3])
       from somemodule import somefunction
       print somefunction(list(a))

   but that reveals details of the implementation of
   somefunction, namely that it can't handle arrays
   directly, even though in most respects arrays
   and lists are interchangeable.

Attached is a patch for the xmlrpclib library that
implements this feature, including minor doc changes and a
new test case.
msg49174 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2005-12-06 04:23
Logged In: YES 

Oh, I forgot my original use case.  I was constructing a list of musicians
from a larger data structure and used a set to guarantee uniqueness
during construction.  I didn't really care about element ordering.  I
either had to convert the set to a list when calling the local function
that made the RPC call, or modify the local function to always convert
that arg to a list.  Both alternatives seemed unattractive to me.
msg49175 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-12-03 12:32
The patch is fine. Notice that it is currently out of date, due to inclusion of patch #1070046.

This other patch added generic support for objects having an __dict__ attribute, marshaling them struct elements. This is in real conflict to this patch: an object both supporting a list conversion and having a __dict__ attribute could be marshaled either way.

My proposal is to resolve this in favor of this patch: If an object has a list conversion, it's most likely meant to be a list.

If you agree to this resolution, please update the code and the documentation, and apply this patch.
msg49176 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2007-02-11 19:14

I'm returning to this after a pause as well...  Suppose I have a subclass of dict.  When dumping with
my proposed patch it will get dumped as a list.  If it is to be dumped as some lowest common
denominator type, it should be a dict I think.  For example:

#!/usr/bin/env python

class D(dict):

d = D(x=1, y=2, z=3)
print d
print list(d)

Until we address is case (at least) I'm un-accepting the patch...

msg49177 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2007-03-11 01:21
Here's a revised patch.  An object having a __dict__ method takes precedence, but an object which can successfully be converted into a list will be transmitted as a list.  No more allow_iter parameter.  Martin, does it look okay to you?


File Added: xmliter.diff
msg55636 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2007-09-04 09:47
I have three problems with the current form of the patch:

a) in the documentation, it should state that __dict__ is an attribute,
not a method.
b) why are you moving the subclassed-from-builtin types into the except
block? It is there to reject things that have an __dict__, but are
derived from a builtin class.
c) Notice that your subclass-from-dict example is flawed. It does have
an __dict__ attribute, but that is *not* the contents to be marshalled:

py> class D(dict):pass
py> d=D()
py> d[1]=2
py> d.__dict__

Here, we would marshal an empty dict, however, the real dict has
contents to be marshalled.

IMO, it's correct to not be able to marshal dict subclasses. People
created them on purpose, and we cannot guess what that purpose was.
msg55640 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2007-09-04 13:28
Thanks for the feedback.  I will reexamine what I've got.
msg114635 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-08-22 01:37
Is anyone interested in this or can it be closed?
msg381373 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2020-11-18 19:45
Skip has abandoned this (removed himself from nosy list) so I'm closing it.
Date User Action Args
2022-04-11 14:56:14adminsetgithub: 42663
2020-11-18 19:45:15iritkatrielsetstatus: open -> closed

nosy: + iritkatriel
messages: + msg381373

resolution: remind -> wont fix
stage: patch review -> resolved
2014-02-03 19:47:30BreamoreBoysetnosy: - BreamoreBoy
2010-08-22 01:37:34BreamoreBoysetversions: + Python 3.2, - Python 2.6
nosy: + BreamoreBoy

messages: + msg114635

type: enhancement
stage: patch review
2010-05-20 20:42:02skip.montanarosetassignee: skip.montanaro ->
2010-05-20 20:33:35skip.montanarosetnosy: - skip.montanaro
2008-04-13 03:30:34skip.montanarosetresolution: remind
2007-09-04 13:28:54skip.montanarosetmessages: + msg55640
2007-09-04 09:47:49loewissetassignee: loewis -> skip.montanaro
messages: + msg55636
2005-12-06 04:14:58skip.montanarocreate