> > 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4