[Python-ideas] Ideas for improving the struct module

[Cameron Simpson]

On 20Jan2017 17:26, Elizabeth Myers <elizabeth at interlinked.me> wrote:
>Some of the responses on the bug are discouraging... mostly seems to
>boil down to people just not wanting to expand the struct module or
>discourage its use. Everyone is a critic. I didn't know adding two
>format specifiers was going to be this controversial. You'd think I
>proposed adding braces or something :/.
>
>I'm hesitant to go forward on this until the bug has a resolution.

Yes, they are, but I think they're being overly negative myself. The struct 
module _is_ explicitly targeted at C structs, and maybe its internals are quite 
rigid (I haven't looked). But as you say, bot NUL terminated strings and run 
length encoded strings are very common, and struct does not support them.

Waiting for a bug resolution seems unrealistic to me; plenty of bugs don't get 
resolutions at all, and to resolve this someone needs to take ownership of the 
bug and decide on something, and that the opposing views don't carry enouygh 
weight.

Why not write a PEP? If nothing else, even if it gets rejected (plenty of PEPs 
are rejected, and kept on record to preserve the arguments) it will be visible 
and on the record. And it will be a concrete proposal, not awash in 
bikeshedding. You can update the PEP to reflect the salient parts of the 
bikeshedding as it happens.

Make it narrow focus, explicitly the variable length thing, just like your 
issue. List the arguments for this (real world use cases, perhaps example real 
world code now and how it would be with the new feature) and the arguments 
against. Describe the additional API (at the least it needs an additional 
calcsize-like function that will return the data length scanned). Make it clear 
that the current API will continue to work unchanged.

Have you read the struct module? Do you think your additions would be very 
intrusive to it, or relatively simple? Will the present performance be likely 
to be the same with your additions (not necessarily to cost to parse the new 
formats, but the performance with any existing fixed length structs)?

Cheers,
Cameron Simpson <cs at zip.com.au>