This patch doesn't include documentation or test suite 
updates yet, and only touches the <

The <nil/> extension is defined at 
http://ontosys.com/xml-rpc/extensions.html.

Outstanding questions:

* To generate <nil/>, an option must be explicitly 
supplied to dumps().  <nil/> is always accepted, 
and it can't be turned off.  Is this OK?  

* Similarly, allow_none is on or off for a ServerProxy; 
you can't turn it on for just one method.  (Seems a 
reasonable limitation...)

* Should the parameter to enable it  be named 
allow_none (Python term) or allow_nil (XML-RPC 
term)?

* When allow_none is false and a None is 
encountered, 
this patch raises a ValueError.  Is that the right 
exception, or should it use xmlrpclib.Error?  Can 
anyone suggest a better message for the exception?

* The FastMarshaller accelerator would also need to 
be updated.

* Are we ever likely to change the default for 
allow_none to True?  If so, how should we arrange 
things so we can warn people?

Logged In: YES 
user_id=21627

On the exception: Currently, you get

TypeError: cannot marshal <type 'NoneType'> objects

and TypeError seems to be the right thing. The message might
read

cannot marshal None unless allow_none is enabled

On allowing None by default: I'd assume that you would want
to disable None only for "strictly-conforming" operation, so
I'd expect to see an option strict (which then defaults to
False). I don't know in what other ways we'd reasonably
deviate from the spec. 

If that ever happens, I don't think a transitional warning
is needed: existing applications continue to work. In
general, in cases that produce an exception now, we don't
need a transition procedure.

Logged In: YES 
user_id=11375

Updated version of the patch: raises TypeError instead of ValueError, and uses Martin's suggested wording; thanks!

Now it's up to /F to accept, decline, or request revisions to this patch.

Logged In: YES 
user_id=21627

Since /F seems unresponsive, I'll accept the patch, on the
provision that it is integrated before Python 2.3b1 (or
after Python 2.3 is released), and that a documentation
change is also committed.

Logged In: YES 
user_id=11375

Should I leave the name of the 'allow_none' parameter alone,
or should I change it to 'strict' and default it to True?

Logged In: YES 
user_id=33168

This was checked in.  Is there anything left to do or should
this patch be closed?

Logged In: YES 
user_id=1197626

Should it be possible to return 'None' from function? I'm having 
problem with this, and I think the "cannot marshal" error is 
coming from the server, not client. However, 
SimpleXMLRPCServer doesn't recognize allow_none as an 
argument?