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