Logged In: YES 
user_id=341410

Curse you Tim, for your core Python experience *wink*.

Pickle is one example where a pascal-like encoding of longs
was an encoding decision made to be flexible and space
efficient.

Certainly we have disparate use cases.  Mine is for fixed
struct-like records with multiple types.  With pickle, any
/thought/ of fixed records are tossed out the window with
variable-lengthed types like strings, longs, lists, tuples
and dicts, and I believe aren't really comparable.  Now,
variable-lengthed longs packed in little-endian format
already have a mechanism for encoding and decoding via
pickle.en/decode_long (though it is wholly undocumented),
and seemingly is going to get another in binascii. 
Fixed-lengthed, optional signed/unsigned, optional
little-endian/big-endian longs do not have a mechanism for
encoding and decoding, which is what I am asking for.

I will point out that 128 bit integers are gaining support
on newer 32 and 64 bit processors and C compilers for them
(SSE on x86, Itanium, etc.).  In the future, a new code for
these 128 bit integers may be asked for inclusion.  With a
variable-width integer type, all future "hey, we now have
x-byte types in C, where is struct support in Python?", can
be answered with the proposed, "choose your integer size"
format code.  That is to say, this format code is future
proof, unless integer types start wandering from integer
byte widths.