[Patches] [ python-Patches-628208 ] xmlrpclib: Optional 'nil' support
noreply@sourceforge.net
noreply@sourceforge.net
Thu, 24 Oct 2002 12:50:00 -0700
Patches item #628208, was opened at 2002-10-24 21:33
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: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Fredrik Lundh (effbot)
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: 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