
On 20Jan2017 17:26, Elizabeth Myers <elizabeth@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@zip.com.au>