XMLRPC standard doesn't support None/nil/null values. Element `<nil/>` was added as an extension to original protocol.

Currently sending None object through xmlrpclib produces `<value><nil/></value>` string. This causes parsing errors in more sophisticated XMLRPC parsers (like org.apache.xmlrpc for Java) which require `<nil/>` element to be declared in namespace for extensions: xmlns:ex='http://ws.apache.org/xmlrpc/namespaces/extensions'

Attached patch makes xmlrpclib use that namespace for sending None values both in method calls and responses, so None value might be passed both ways. It isn't bound to use fixed prefix for extensions namespace and it also parses XML produced by original xmlrpclib (without any namespace at all), so it is backward compatible.

It does its job communicating with org.apache.xmlrpc library now, using default parser on the Python side which is an improvement to original version, so I'd like to see it included in the next Python 2.x release, if possible.

Thanks for the report and patch.  You may find the following guidelines useful for your future contributions: http://www.python.org/dev/patches/

I have two questions about the proposed fix.  First, this line caught my eye:

  if tag.split(':')[1] == 'nil':

It seems wrong to handle a nil element from any namespace the same way.  I think namespaces should be supported properly or not at all.

Second point, can you point us to documentation about nil?  The Wikipedia article about XML-RPC and http://ontosys.com/xml-rpc/extensions.php agree that nil should not be a child of value, but say nothing about a namespace.  If it’s a band-aid for one specific server, I don’t think it’s acceptable.

Ok, I apologize for being to hasty. Below you can find my answers:

1. SlowParser used in xmlrpclib doesn't deal with namespaces in any reasonable way. If there's a namespace prefix for tag, it's not separated from tag name, but passed as part of tag name. But I agree - this should be done better.

2. Well, I suppose that content of http://ws.apache.org/xmlrpc/extensions.html will only convince you that this patch is just for Java library and you reject it. I didn't find support for <nil/> in Perl nor Ruby. One of PHP libraries also support <nil/> (and <ex:nil/>) - http://phpxmlrpc.sourceforge.net/, but AFAIK it doesn't require/provide any namespace at all. It just treats ex:nil as a synonym for nil, probably to be compatible with Apache library.

All in all - I think that my patch should be rejected. I can send simpler patch that would work like phpxmlrpc does - just accept ex:nil as well as nil and not try to analyze namespaces at all.

On Tue, Nov 16, 2010 at 11:32:03AM +0000, Adam Bielański wrote:
>  just accept ex:nil as well as nil and not try to analyze namespaces at all.

But even that seems specific to Java/ Apache Extension.
If it is, then it might go in as part of issue8792.

It is. It might go. Didn't notice issue8792 before, thanks for pointing it out.

Whole ex:nil issue is discussed there, so this issue might be closed.

There's no need to apologize, we welcome contributions like your report and are open to discuss patches :)

In case it isn't clear from the discussion in issue8792: I'd be in favor of supporting extensions as long as their usage is an opt-in feature. The current nil support is already an opt-in feature. If alternative spellings of nil need to be supported, or other extensions, it might be necessary to refactor this extension support a bit, so that extensions can be independently be developed and activated.

As for Python's usage of nil: it is specified in

http://ontosys.com/xml-rpc/extensions.php

and also referenced in the Wikipedia. IMO, it would have been better if Apache had used the pre-existing extension, instead of coming up with its own (supposedly only because the pre-existing one wasn't namespace-based).