[Python-Dev] proposed struct module format code addition

[Josiah Carlson]

> > The suggested alternative is adding two functions to binascii that
> > parallel the existing hexlify() and unhexlify().
> 
> Those functions ought to exist whether or not this RFE is accepted.

No argument here.  I believe the binascii and struct additions have
orthogonal use-cases.


> Here's the crux I think. Is this used often enough in a context where
> (a) the length of the number is fixed (not determined by a count in a
> previous field) and 

All use-cases I have for it, yes.  Seemingly this is a yes with Bob
Ippolito as well (he stated he uses 3, 6 and 16 byte integers, which
certainly seem fixed).


> (b) preceded or followed by other fixed-length
> fields so that it makes sense to use the struct module for parsing or
> formatting those other fields?

In my case, yes.  As provided in the email, two that I use right now are
'H3G3G' and '3G5G'.


> I have often found that amongst less-experienced programmers there is
> a great mystery about the correspondence between the "binary"
> representation of numbers (in strings of bytes) and the numeric
> objects that Python makes available (int, lont). Often the struct
> module is considered the only way to cross this boundary, while in
> fact there are many other approaches; often using the built-in
> functions ord() or chr() and shifting and masking works just as well,
> but you have to think about it the right way.

Indeed, this /can/ be the case, but it is not in my case.  Before I knew
of struct, I had written my own binary packers and unpackers using ord
and chr. While it worked, I nearly wept with joy when I discovered
struct, which did 90% of what I needed it to do, in a much cleaner
fashion.


> I apologize for not having read the entire post  before responding; in

Yeah, it was a bit long, I believed there was a lot to say.


 - Josiah