The 'p' format specifier is also not a standard C type, and yet it is included in struct, specifically because it is useful.
I never used it <wink>.
If you have used PostgreSQL, all strings are a variant of pascal strings. It may be the case in other databases, but I have little experience with them.
My Response: That is not the same. Nontrivial problems require multiple passes over your data with multiple calls. A simple: struct.unpack('H3G3G', st)
My problem with that use case is that I've never had it, and have never seen an app that had it. Since I've been around for decades, that triggers a suspicion that it's not a common need.
It may be domain specific.
I've only been using Python for 4 1/2 years, yet I have used such structs to build socket protocols, databases and search engines, for both class and contract. Heck, I find it useful enough that I have considered donating to the PSF just to see this feature included.
Argument: The struct module has a steep learning curve already, and this new format specifier doesn't help it.
That's another argument I haven't seen before, but bears an hallucinatory resemblance to one I made. People have wondered how to
This was one argument that Raymond has offered a few times. In the case of native alignment issues that seem to be the cause of much frustration among new struct learners, this particular format specifier doesn't much apply; it is not native.
binascii" would be a direct answer to their question, and one that
So there is no confusion, I agree with Raymond, Guido, and you, that the binascii function additions should occur.
Newbie confusion about how to use struct is common on c.l.py, and is especially acute among those who don't know C (just *try* to read the struct docs from the POV of someone who hasn't used C).
Good point about the docs regarding not using C. Does it make sense to include documentation regarding C structs (perhaps in an appendix) to help those who have otherwise not experienced C?
I certainly would like to see more people say they'd *use* the g and G codes in struct even if "one shot" functions in binascii were available.
<raise hand> <wink>
I'd also like to see a specific design for binascii functions. I don't think "simple" would be an accurate description of those, if they're flexible enough to handle the common use cases I know about. They'd be more like
[snip conversion operations]
Those would work great for packing and unpacking of single longs.