>>>>> "SM" == Skip Montanaro <skip@pobox.com> writes:
Jeremy> It sounds like such a function would not be particularly
Jeremy> useful for XML-RPC, but I can imagine it would be useful in
Jeremy> a world where programmers don't worry about whether they
Jeremy> have an int or a long.
SM> Ah, okay. I was only looking at your note through
SM> XML-RPC-colored glasses. I thought PEP 237 was supposed to
SM> handle the int/long unification. Presumably, after it is fully
SM> in effect, int("9999999999999999999999999") will just return a
SM> long, maybe not.
If that happens, we'll need to fix xmlrpclib so that it doesn't
marshal int that don't fit in 4 bytes :-).
Jeremy> Incidentally, it looks like the XML-RPC code won't work with
Jeremy> subclasses of built-in types. It's does dispatch on the
Jeremy> type() of the object, but a subclass of string won't have
Jeremy> type StringType. It seems to me, though, that it should be
Jeremy> marshallable using XML-RPC.
SM> I filed a bug report just so this thought wouldn't get lost:
SM> http://sourceforge.net/tracker/index.php?func=detail&aid=469972&group_id=5470&atid=105470
SM> I don't know if that's a bug report or a feature request though.
SM> Xmlrpclib doesn't currently marshal instances of classic
SM> classes, so I'm not so sure it should marshal instances of
SM> new-style classes either. It's Fredrik's and Martin's call.
It seems like it ought to handle subclasses of builtin classes like
string.
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