Logged In: YES 
user_id=72053

Skip - C has struct objects which are sort of like Python
dictionaries.  XMLRPC represents structs as name-value
pairs, for example.  And "other languages" doesn't
necessarily mean C.  The marshaller should be able to
represent the non-Python-specific serializable objects,
not just scalars.
Basically this means strings, integers (of any length),
dictionaries, lists, and floats (hmm--unicode?), but
not necessarily stuff like code objects.

Having an independent marshal library is ok, I guess,
though I don't feel it's necessary to create more
implementation work.  And one the benefit of using
the existing marshaller is that it's already available in
most versions of Python that people are running
(Red Hat 7.1 still comes with Python 1.5 for example).

Tim - yes, I'm originally used a binascii.hexlify hack
similar to yours and it worked ok, but it was ugly.  I
also had to handle strings (generate a length count
followed by the contents) and then dictionaries (name-value
pairs) and finally felt I shouldn't need to rewrite the
marshaller like that.  There's already a built-in library
function that does everything I need, very efficiently in
native code, in one call, and being able to use it is in
the "batteries included" spirit.  

Also, the current long int marshalling format
is just a digit count (16-bit digits) followed by the digits
in binary.  If the digit width changes, the marshalling
format doesn't have to change--the marshalling code should
still be able to use the same external representation 
without excessive contortions and without slowing down.
(You'll see that it's already not a simple memory dump,
but a structure read and written one byte at a time through
layers of subroutines).  Changing widths while keeping the
old format means putting a minor kludge in the marshalling
code, but no user will ever notice it.

As for the speed of Python longs,
my stuff's runtime is dominated by modular exponentiations
<wink> and I'm already using gmpy for those when it's 
available (but I don't depend on it).  The speedup with
gmpy is substantial, but the speed with ordinary Python
longs is quite acceptable on my PIII (the StrongARM is
another story--probably the C compiler's fault).

Examining Python/marshal.c, I don't see any objects of
the types I've mentioned that are likely to need to change
representations--do you?  

Btw I notice that the pickle module represents long ints
as decimal strings even in "binary" mode, but I'll resist
opening another bug for that, for now.