[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2020-09-21 Thread desbma
Change by desbma : -- nosy: +desbma ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/ma

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2015-01-29 Thread Martin Panter
Martin Panter added the comment: The non-blocking behaviour that I documented in my patch is under question in Issue 13322. I think it would be nice change the implementation to either return None or raise BlockingIOError. -- ___ Python tracker

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2015-01-09 Thread Martin Panter
Martin Panter added the comment: Here is a simple documentation patch to guarantee that at least one byte is normally returned. This would make the method much more useful, and compatible with the BZ2File and LZMAFile interfaces, allowing them to use BufferedReader, as I propose to do in Issue

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2015-01-09 Thread Martin Panter
Martin Panter added the comment: Is the current documentation as accurate as it can be? “The number of bytes returned may be less or more than requested” To me this has always made this method practically useless. A valid implementation could just always return b"". I noticed the BZ2File.peek(

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2014-02-03 Thread Mark Lawrence
Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2013-05-19 Thread Mark Lawrence
Mark Lawrence added the comment: Looks like this has slipped under the radar. I'll leave working on it to the experts :) -- nosy: +BreamoreBoy ___ Python tracker ___ ___

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-15 Thread Lucas Prado Melo
Lucas Prado Melo added the comment: Ok A new patch without read1() changes. Only one test fails, a read1() test: == FAIL: test_read1 (test.test_io.PyBufferedRWPairTest) --

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-15 Thread Nick Coghlan
Nick Coghlan added the comment: The doc revision definitely does a better job of characterising the current underspecified behaviour :) I agree with Antoine that "at most a single read" would be better wording. -- ___ Python tracker

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-15 Thread Antoine Pitrou
Antoine Pitrou added the comment: I haven't read the patch in detail but I don't think you should have changed read1(). read1() is there for optimization purposes and its current behaviour makes sense IMO. -- versions: +Python 2.7 ___ Python tracker

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-14 Thread Lucas Prado Melo
Lucas Prado Melo added the comment: Here, it's a patch that passes all the tests (I had to change some of them though, they were expecting erroneous behaviours IMHO). The biggest problem was the read1 testing, I've tried to get the maximum of bytes less than or equal to what the user wanted whil

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-14 Thread Lucas Prado Melo
Lucas Prado Melo added the comment: Here is a patch that passes all the tests (I had to change some of them though, they were expecting erroneous behaviours IMHO). The biggest problem was the read1 testing, I've tried to get the maximum of bytes less than or equal to what the user wanted while e

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-14 Thread Antoine Pitrou
Antoine Pitrou added the comment: Rather than "only a single read on the raw stream", it should be "at most a single read on the raw stream", IMHO. -- ___ Python tracker ___

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-14 Thread Benjamin Peterson
Benjamin Peterson added the comment: I updated the documentation in r73429. Is that better? -- versions: +Python 3.2 -Python 3.0 ___ Python tracker ___ __

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-13 Thread Nick Coghlan
Nick Coghlan added the comment: It's not the docstring that is wrong for the current behaviour, it's the IO.BufferedReader documentation: """ peek([n]) Return 1 (or n if specified) bytes from a buffer without advancing the position. Only a single read on the raw stream is done to satisfy th

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-13 Thread Benjamin Peterson
Benjamin Peterson added the comment: I'm downgrading this because it can't be changed until after 3.1 is released. -- assignee: benjamin.peterson -> priority: release blocker -> normal ___ Python tracker _

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-13 Thread Antoine Pitrou
Antoine Pitrou added the comment: > We could fill the buffer while moving its start point to 0. I guess this > behavior would require a new function (or a new parameter to > Modules/_io/bufferedio.c:_bufferedreader_fill_buffer() ). > If you are ok with that I could write a patch. The buffer is

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-13 Thread Antoine Pitrou
Antoine Pitrou added the comment: We could, however, enforce the passed argument and only return the whole remaining buffer when no argument is given. This is a bit like Frederick Reeve's proposal on python-dev, but less sophisticated and therefore less tedious to implement. In any case, I'm no

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-13 Thread Lucas Prado Melo
Lucas Prado Melo added the comment: We could fill the buffer while moving its start point to 0. I guess this behavior would require a new function (or a new parameter to Modules/_io/bufferedio.c:_bufferedreader_fill_buffer() ). If you are ok with that I could write a patch. --

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-13 Thread Antoine Pitrou
Antoine Pitrou added the comment: Lucas, it is indeed impossible for peek() to return more than the buffer size and remain compatible with non-seekable raw streams. That's why it /never/ returns more than the buffer size. As for the fact that peek() doesn't behave as documented, I disagree. Her

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-12 Thread Lucas Prado Melo
Lucas Prado Melo added the comment: There's a problem with my patch... When the size of the data we want to peek is too big ( > buffer_len - start ) the cursor will move, thus there isn't a case where the peek function would work properly (except when we want to peek() just 1 byte). Couldn't we

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-12 Thread Lucas Prado Melo
Lucas Prado Melo added the comment: Oops I overlooked I minor flaw. A second version. -- Added file: http://bugs.python.org/file14282/peek2.diff ___ Python tracker ___ __

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-12 Thread Lucas Prado Melo
Lucas Prado Melo added the comment: Hey guys, I did a patch about this one. I didn't do many tests but I guess it is ok (it works like I think it should). What do you think? -- keywords: +patch nosy: +conf Added file: http://bugs.python.org/file14281/peek.diff _

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-12 Thread Benjamin Peterson
Benjamin Peterson added the comment: I think the argument should be used as a upper bound; I will look at this tomorrow. -- ___ Python tracker ___ ___

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-06-12 Thread Nick Coghlan
Nick Coghlan added the comment: Assigned to Benjamin for assessment - this should be considered for rc2 since it's still broken in 3.1: >>> f = open('setup.py', 'rb') >>> len(f.peek(10)) 4096 >>> len(f.peek(1)) 4096 >>> len(f.peek(4095)) 4096 >>> len(f.peek(10095)) 4096 Brought up on python-d

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-04-21 Thread Torsten Rottmann
Torsten Rottmann added the comment: Proposed patch to fix this: set the default of n to 1 as stated by docs: def _peek_unlocked(self, n=1): return n bytes: return self._read_buf[self._read_pos:self._read_pos+n] -- ___ Python tracker

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-04-21 Thread Torsten Rottmann
Torsten Rottmann added the comment: Note: this is also in Python 2.6 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

2009-04-21 Thread Torsten Rottmann
New submission from Torsten Rottmann : The documented behavior of io.BufferedReader.peek([n]) states: peek([n]) Return 1 (or n if specified) bytes from a buffer without advancing the position. Thereas the parameter n is the _max_ length of returned bytes. Implementation is: def _peek_unl