[Python-Dev] proposed struct module format code addition
jcarlson at uci.edu
Sun Oct 3 20:22:30 CEST 2004
> > 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
> 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
> 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.
More information about the Python-Dev