[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