Nick Coghlan <ncogh...@gmail.com> 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-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.
----------
assignee: -> benjamin.peterson
nosy: +benjamin.peterson, ncoghlan
priority: -> release blocker
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
