>>>>> "SM" == Skip Montanaro <skip@pobox.com> writes: SM> xmlrpclib.py Log Message: allow long ints to be marshalled as SM> ints - no check is made to the incoming value, so the programmer SM> will have to catch OverflowError. Jeremy> How does the other end unmarshal it? You shouldn't get Jeremy> overflow errors any more. Jeremy> Oh, well, actually you do still get overflow and value Jeremy> errors from the builtin int(). SM> The receiving end will unmarshal the object into an int. Sorry to repeat myself but: "Jeremy> How does the other end unmarshal it?" Jeremy> I wonder if there should be a generic number-from-string Jeremy> conversion function that returns either a long or an int as Jeremy> needed. If an integer literal in your program text can Jeremy> produce a long, why can't builtin int()? SM> Not sure what you're getting at here. I meant to say "I wonder if Python should provide a generic string-to-number conversion routine that returns either an int or a long." SM> The XML-RPC spec also SM> indicates that the <int> tag is restricted to the value that can SM> be represented by a four-byte signed integer. It sounds like such a function would not be particularly useful for XML-RPC, but I can imagine it would be useful in a world where programmers don't worry about whether they have an int or a long. Incidentally, it looks like the XML-RPC code won't work with subclasses of built-in types. It's does dispatch on the type() of the object, but a subclass of string won't have type StringType. It seems to me, though, that it should be marshallable using XML-RPC. Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4