Logged In: YES 
user_id=31435

Ack -- Paul, you add a new hitherto secret <wink> 
requirement with each reply.

marshal isn't secure at all:  because its *purpose* is to 
load .pyc files, marshal creates Python code objects out of 
any bytes you happen to feed it following a "code object" 
tag.  That's a hole big enough to swallow the solar 
system.  In 2.2, marshal refuses to unpack code objects in 
restricted execution mode, but not before 2.2, and it never 
refuses in unrestricted mode.

In contrast, pickle doesn't know anything about code 
objects, so doesn't have this hole.  The pickle docs are 
clear about this, too, spelling out that marshal's code-
object abilities create "the possibility of smuggling 
Trojan horses into a program".

When wondering about security, you should be looking at 
(and using) cPickle.c instead of pickle.py; cPickle doesn't 
use marshal at all, nor does it do eval()s etc.  Yes, it 
can reconstruct pickled instances of classes that already 
exist, but it cannot create new classes.  I haven't heard 
that characterized as an insecurity before, but to each his 
own level of discomfort.

I want to go back to the start:  if the question is whether 
Python is interested in documenting another data 
transmission format, my answer is no.  There are many 
already (don't forget the ones from the CORBA and ILU 
worlds either) available from Python, and there's no reason 
to believe encoders/decoders for a Python-specific format 
would get implemented in any other language.

pickle is Python's generic answer to the Python-specific 
serialization question.  I'd be happy to see patches to 
improve it (whether for efficient longs, or some stricter 
notion of security, or even just docs).  But I expect any 
additional Python-specific serialization scheme has an 
audience of one (if you disagree, fine, write a PEP and get 
some community consensus).