Agreed. On Thu, Jan 23, 2014 at 3:36 AM, Gustavo Carneiro <[email protected]> wrote: > > > > On 23 January 2014 11:30, Victor Stinner <[email protected]> wrote: >> >> Hi, >> >> I found the StreamReader.readexactly(n) function which has a strange >> behaviour. It reads exactly n bytes... but it returns less if the end >> of stream is reached. >> >> Why not raising an exception? When I use such function, I expected to >> get... exactly... n bytes, not "almost" n bytes :-) >> >> It would be annoying to write: >> >> data = reader.readexactly(n) >> if len(data) != n: ... >> >> For each call to readexactly(). I prefer to write optimistic code and >> maybe catch an exception if needed. >> >> We may raise an exception with the incomplete data. For example, >> subprocess.check_call() raises an exception which contains the return >> code, the command and the output. The io module uses a BlockingIOError >> which contains the number of written bytes. >> >> The code even contains this comment: >> >> # TODO: Raise EOFError if we break before n == 0? (That would >> # be a change in specification, but I've always had to add an >> # explicit size check to the caller.) >> >> I opened an issue with a patch to raise an IncompleteReadError which >> inherits from EOFError and contains the partial data: >> http://code.google.com/p/tulip/issues/detail?id=111 >> > > +1 > > I think reader.readexactly(n) is meant to be called in the context of a > protocol where less than n bytes would be a protocol violation, anyway. > Usually, protocol violations are rare (are really exceptional) and can be > handled in a coarse-grained try: .. except: .. block. > > > -- > Gustavo J. A. M. Carneiro > Gambit Research LLC > "The universe is always one step beyond logic." -- Frank Herbert
-- --Guido van Rossum (python.org/~guido)
