Author ncoghlan
Recipients benjamin.peterson, ncoghlan, trott
Date 2009-06-13.02:27:12
SpamBayes Score 2.93035e-08
Marked as misclassified No
Message-id <1244860036.5.0.572390856198.issue5811@psf.upfronthosting.co.za>
In-reply-to
Content
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-dev in this thread:
http://mail.python.org/pipermail/python-dev/2009-June/089986.html

And previously here:
http://mail.python.org/pipermail/python-dev/2009-April/088229.html

The thread from April suggests the current behaviour may be intentional,
in which case it is the documentation that needs to be fixed, as it is
currently not just misleading but flat out wrong. Then again, Benjamin's
initial response to that thread was to support the idea of changing
peek() so that the argument actually was a cap.

The previous documentation that Alexandre quotes in the April was
changed to the current description in late April without any
corresponding change to the implementation:
http://svn.python.org/view/python/branches/py3k/Doc/library/io.rst?r1=62422&r2=62430

However, the old description was also wrong for the io-c implementation
since it just returns the current buffered data from peek, no matter
what argument you pass in.
History
Date User Action Args
2009-06-13 02:27:16ncoghlansetrecipients: + ncoghlan, benjamin.peterson, trott
2009-06-13 02:27:16ncoghlansetmessageid: <1244860036.5.0.572390856198.issue5811@psf.upfronthosting.co.za>
2009-06-13 02:27:13ncoghlanlinkissue5811 messages
2009-06-13 02:27:12ncoghlancreate