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.