On 20 January 2017 at 20:47, Elizabeth Myers <elizab...@interlinked.me> wrote:
> Two things:
>
> 1) struct.unpack and struct.unpack_from should remain
> backwards-compatible. I don't want to return extra values from it like
> (length unpacked, (data...)) for that reason. If the calcsize solution
> feels a bit weird (it isn't much less efficient, because strings store
> their length with them, so it's constant-time), there could also be new
> functions that *do* return the length if you need it. To me though, this
> feels like a use case for struct.iter_unpack.
>
> 2) I want to avoid making a weird incongruity, where only
> variable-length strings return the length actually parsed. This also
> doesn't really help with length calculations unless you're doing
> calcsize without the variable-length specifiers, then adding it on. It's
> just more of an annoyance.

Fair points, both. And you've clearly thought the issues through, so
I'm +1 on your decision. You have the actual use case, and I'm just
theorising, so I'm happy to defer the decision to you.

Paul
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to