On Wed, 26 Dec 2018 at 09:26, Steven D'Aprano <st...@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. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
