[Patches] [ python-Patches-628208 ] xmlrpclib: Optional 'nil' support

SourceForge.net noreply@sourceforge.net
Sat, 19 Apr 2003 01:01:00 -0700


Patches item #628208, was opened at 2002-10-24 21:33
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
>Assigned to: A.M. Kuchling (akuchling)
Summary: xmlrpclib: Optional 'nil' support 

Initial Comment:
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?


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 10:01

Message:
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.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-10-29 17:44

Message:
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.



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-24 21:50

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470