[Patches] [ python-Patches-628208 ] xmlrpclib: Optional 'nil' support
SourceForge.net
noreply at sourceforge.net
Sat Jul 9 16:29:03 CEST 2005
Patches item #628208, was opened at 2002-10-24 22:33
Message generated for change (Comment added) made by jpa-
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.3
Status: Closed
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: jpa (jpa-)
Date: 2005-07-09 17:29
Message:
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?
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-26 04:20
Message:
Logged In: YES
user_id=33168
This was checked in. Is there anything left to do or should
this patch be closed?
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2003-04-20 22:06
Message:
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?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 11: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 18: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 22: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
More information about the Patches
mailing list