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.

Author phr
Recipients
Date 2001-10-14.00:49:55
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=72053

I agree with Tim that the internal implementation of long
arithmetic isn't relevant to this--it was just surprising,
and means the current marshal format isn't all that natural
for external use.

I don't have a particular agenda to get marshal documented,
beyond that it would happen to solve my immediate problem.
Alternatives are fine too.  The ones suggested so far
just don't seem to do the job, viz.:

xmlrpc does NOT serialize basic Python objects--in
particular it doesn't serialize integers longer than 32
bits.  I can't consider using pickle until I've convinced
myself that it doesn't make security holes, and so far it
looks like the opposite.  (Can someone tell me I'm not
reading it right?).

Yes, of course, it's not that difficult to write Python
code to do everything I want.  It's just surprising that
I should need to do that.  I mean, imagine if there was
no integer addition function (no "+" operator) and the
maintainers said "that's ok, to add a and b, just use
'a - (-b)'".  It's not a showstopping obstacle, but I'm
surprised to get so much grief for suggesting making the
operation more convenient, since it's an obvious thing
to want to do (as evidenced by there already being so many
overlapping serialization functions: marshal, pickle, 
rpclib, the Serialization class from Vaults of Parnassus,
three different ASN1 implementations you mentioned, etc).

I can't see anywhere where I've requested a "special
gimmick".  Yes, an efficient bigint representation in pickle
is nice and ought to be added, but I can live without it.
I can NOT live with security holes, but wanting security
shouldn't be considered a special gimmick!  With binary
bigints, a documented format, and a way to 100% stop the
unpickler from ever calling eval or apply on untrusted
data, I wouldn't mind using pickle despite its additional
complexity compared to marshal. 

I don't want to depend on third party modules unless I 
bundle them with my application (again not a showstopper,
but it's not in Python's "batteries included" spirit to need
them at all).  Telling a user "to run this app, first
download modules vreeble from <url1> and frob from <url2>"
where url1 and url2 usually turn out to be broken links
by the time the user sees them is not the right way to
distribute an app.  (It happens I'm going to sometimes
tell the user "to run this app, first destroy your
handheld computer's OS by reflashing the firmware..."
but it's the principle of the thing, you know).

Anyway, the 15 bit bigint representation is reason enough
to not want to freeze the current marshal format.
Maybe a future marshaller can use a cleaner bigint format
and at that point perhaps the issue can be revisited.
History
Date User Action Args
2007-08-23 16:01:35adminlinkissue467384 messages
2007-08-23 16:01:35admincreate