[Python-Dev] proposed struct module format code addition

[Josiah Carlson]

> >    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.

 - Josiah