Issue1084279
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2004-12-13 10:07 by pitrou, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
xmlrpc.diff | rhettinger, 2004-12-13 13:13 | Helper function for non-exponential representations. |
Messages (9) | |||
---|---|---|---|
msg23673 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2004-12-13 10:07 | |
Hi, I've been reading through the xmlrpclib.py code to see that floats are marshalled the following way: def dump_double(self, value, write): write("<value><double>") write(repr(value)) write("</double></value>\n") dispatch[FloatType] = dump_double Using repr() means that small or big floats, for example, will be output using the exponent notation: >>> repr(2**-15) '3.0517578125e-05' Unfortunately, the XML-RPC specification does not allow this notation: "At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified." (http://www.xmlrpc.com/spec) Thus floats marshalled using xmlrpclib may not be readable using other XML-RPC implementations. (I don't have any concrete data about this though) |
|||
msg23674 - (view) | Author: Raymond Hettinger (rhettinger) * | Date: 2004-12-13 12:40 | |
Logged In: YES user_id=80475 I loaded a recipe for a helper function that meets the spec: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361 Inserting and applying the helper function ought to be backwards compatible (the new encoding is readable by previous versions). Martin, do you agree with approach and concur that it should be backported? |
|||
msg23675 - (view) | Author: Raymond Hettinger (rhettinger) * | Date: 2004-12-13 13:13 | |
Logged In: YES user_id=80475 See attached patch. |
|||
msg23676 - (view) | Author: Skip Montanaro (skip.montanaro) * | Date: 2004-12-13 15:38 | |
Logged In: YES user_id=44345 I understand what you''re doing, but I wonder if in the process interoperability with other XML-RPC implementations might actually get worse. While the spec doesn't support exponential notation, most programming languages do, and probably happily accept "1.234e-147" as a floating point input. Python seems not to have problems accepting floating point inputs with huge numbers of zeroes before or after the decimal point, but other languages may not be quite so forgiving. I think we need to be a bit careful before changing our implementation. At the very least we should probably verify the acceptance of non_e_repr-generated strings by a few other languages commonly used with XML-RPC (C, Perl, Tcl, Ruby?). |
|||
msg23677 - (view) | Author: Raymond Hettinger (rhettinger) * | Date: 2004-12-13 18:12 | |
Logged In: YES user_id=80475 The thought was "be liberal in what you accept and be strict on was is emitted." Still, the question is valid. For C, it looks like strtod() is at the root of everything converting from floats. The spec lays no limits on the input format (exponents vs full decimal representation). Instead, it just checks that the result is inside the range of representable values and did not underflow. Some experiments with MSC6 confirm that the full range may be entered as regular decimals. Experiments with Perl show the same result. I suspect all TCL and Ruby also have strtod() at the core. |
|||
msg23678 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2004-12-13 19:04 | |
Logged In: YES user_id=133955 I'm gonna ask a stupid question (I'm quite a beginner in Python). Why isn't there a %f-life formatting code for doing just what you wrote - printing the float in full precision in non-exponent format ? |
|||
msg23679 - (view) | Author: Raymond Hettinger (rhettinger) * | Date: 2004-12-13 22:19 | |
Logged In: YES user_id=80475 Various slightly unsatisfactory answers: * It started out that way because that's what C did. * It stayed that way because no one has requested it * It may be that outside of XMLRPC there are very few valid use cases. * Future needs can be met by the decimal module. |
|||
msg23680 - (view) | Author: Raymond Hettinger (rhettinger) * | Date: 2004-12-16 10:32 | |
Logged In: YES user_id=80475 After more thought, I'm concerned that switching to full decimal notation will break the guarantee eval(repr(x))==x. Also, Skip's thoughts seem reasonable. Rather than switching to a non-compact format, it may be best to way for the spec to catchup with real implementations. |
|||
msg23681 - (view) | Author: Tim Peters (tim.peters) * | Date: 2004-12-17 20:30 | |
Logged In: YES user_id=31435 FWIW, I'd leave this alone. The XML-RPC spec is braindead when it comes to floats, and any implementation that didn't accept scientific notation would have to go out of its way to cripple the facilities all languages with a string->double function supply. Raymond, under any IEEE-conforming string->double implementation, eval(repr(x))==x will hold provided that repr (x) be roughly correct to at least 17 significant decimal digits, and that x is finite. It doesn't matter whether the string uses exponent notation. OTOH, IIRC Python got in trouble once with some old Solaris string->double C routine that went insane if the string had "too many" characters. Indeed, making bad assumptions about maximum string length seems a lot more likely to me than that someone has a string- >double routine that can't deal with exponents. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:08 | admin | set | github: 41315 |
2004-12-13 10:07:48 | pitrou | create |