[Python-ideas] struct.unpack should support open files

[Paul Moore]

On Wed, 26 Dec 2018 at 09:26, Steven D'Aprano <steve at pearwood.info> wrote:
> Regardless, my point doesn't change. That has nothing to do with the
> behaviour of unpack. If you pass a non-blocking file-like object which
> returns None, you get exactly the same exception as if you wrote
>
>     unpack(fmt, f.read(size))
>
> and the call to f.read returned None. Why is it unpack's responsibility
> to educate the caller that f.read can return None?

Abstraction, basically - once the unpack function takes responsibility
for doing the read, and hiding the fact that there's a read going on
behind an API unpack(fmt, f), it *also* takes on responsibility for
managing all of the administration of that read call. It's perfectly
at liberty to do so by saying "we do a read() behind the scenes, so
you get the same behaviour as if you did that read() yourself", but
that's a pretty thin layer of abstraction (and people often expect
something less transparent).

As I say, you *can* define the behaviour as you say, but it shouldn't
be surprising if people expect a bit more (even if, as you've said a
few times, "no-one has asked for that"). Designing an API that meets
people's (often unstated) expectations isn't always as easy as just
writing a convenience function.

Paul

PS I remain neutral on whether the OP's proposal is worth adding, but
the conversation has drifted more into abstract questions about what
"needs" to be in this API, so take the above on that basis.