Weaknesses of xml_pickle
xml_pickle lacks some types that many programming languages have. If our goal is not simply to save and restore Python objects, but to exchange objects across languages, then
is not currently quite adequate. The issue of floats and integers is not
really important in principle; but designing an "unpickler" for, say,
Java would be easier if the XML parser were able to determine the type
needed, rather than defer that until the format of the
value attribute is analyzed.
Of more serious concern for cross-language pickling are the
<dateTime.iso8601> tags that XML-RPC has, but Python lacks as a built-in type. Even though I claimed that
handled user classes that define custom data types easily and well, this
is not quite as true when it comes to the cross-language case. For
example, the fragment of an
xml_pickle representation in Listing 6 describes an iso8601 Date/Time:
Two issues make it difficult to utilize this data in, say, Perl or REBOL or PHP. One is the namespace of the restored class. In
Python, the namespace of the restored
xmlrpclib.DateTime becomes, by default,
(but the namespaces can be manually manipulated prior to unpickling).
The way Python's instantiation and namespaces work, little rests on
this fact, at least not if we're interested in the instance attributes
rather than its methods. But various languages handle scoping matters
in very different ways.
The second and far more important issue
is the fact that this custom class cannot be easily recognized as a
native type in languages where it is one. Perl and PHP do not have a
DateTime type anyway, so nothing is really lost as long as unpicklers in those languages restore the
instance attribute. REBOL, by contrast, has many more native data types
-- not just dates, but also exotic types like e-mail addresses and
URLs. These are lost in the
xml_pickle process. Of course,
XML-RPC also loses those data types. Either way, we are left with plain
string type to represent something more specific (or
<base64> in XML-RPC, which
xml_pickle handles by escaping high bit values -- for example, "\xff").