Logged In: YES 
user_id=341410

Hexlify and unhexlify make sense for translating strings. 
Nowhere in the binascii module is there any mention of
translating anything to/from integers, longs or floats.  The
only reason (un)hexlify make any sense at all is because we
can get integers from hexlified strings, and get strings
from hexlified integers with relative ease.

I guess the trick with struct, at least with me, is not that
I use it because it translates to/from C types, it is
because it translates to/from types that I find useful.  Its
intersection with C types, as well as Python's intersection
with C types, and my use intersection with the types is a
convenient (but very engineered and understandable) coincidence.

It would be another very convenient (but also engineered
*wink*) coincidence if I didn't have to first extract a
section of data, then translate it, in order to get one
large integer.

In the cases that I would truely find useful, big integers
are a part of what would be called structs in the C world,
and wouldn't require additional processing over what I'm
already doing for other integers and floats.


I was looking around, and it turns out that in 2001, Paul
Rubin requested that one be able to translate to/from
arbitrary bases via the C-level format function.  In that
discussion, Paul made the case that there should be a method
to get arbitrarily long integers to and from strings:
"The struct module doesn't give any way of converting
arbitrary ints (meaning longs) to binary.  Really, it's
needed.  Some people do it with gmpy, but if Python is
going to support longs as a built-in type, one shouldn't
have to resort to 3rd-party modules to read and write
them in binary."

Guido followed up with:
"OK, I believe you.  Can you submit a patch?"

It seems like this was in reference to being able to use
functions in binascii for converting to/from arbitrary
packed binary integer types in base 256
(http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470
if you are interested).  That request seems to have died
because Paul dropped the ball.

Me, I would prefer struct to binascii, if only because the
code for doing this is already waiting to be used in struct,
and because you can pull multiple objects from a single
packed binary string, rather than one object per call.  This
would seemingly also satisfy complaints of being able to
translate to/from base 256 for arbitrarily large integers.