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/
