[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Changes by Donald Stufft : -- pull_requests: +1074 ___ Python tracker ___ ___

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Changes by Martin Panter : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Roundup Robot added the comment: New changeset 2af6d94de492 by Martin Panter in branch 'default': Issue #23214: Fix formatting of -1 https://hg.python.org/cpython/rev/2af6d94de492 -- ___ Python tracker

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Martin Panter added the comment: Modifying the API to accept a keyword argument is not worthwhile IMO. That means modifying modules like http.client and zipfile (which use the wrong keyword name), and user-defined implementations may become incompatible. The question of documentation is

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

STINNER Victor added the comment: 2016-10-21 5:17 GMT+02:00 Martin Panter : > The idea of changing the signature is to avoid people thinking it accepts a > keyword argument. See e.g. Issue 25030 for seek(offset, whence=SEEK_SET), > Issue 14586 for truncate(size=None).

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Martin Panter added the comment: The minus sign might have been deliberate at some stage, but I realize it is more accessible etc if it was ASCII -1, so I will change that. The idea of changing the signature is to avoid people thinking it accepts a keyword argument. See e.g. Issue 25030 for

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

STINNER Victor added the comment: - .. method:: read1(size=-1) + .. method:: read1([size]) I don't understand this change: the default size is documented as -1. Did I miss something? + If *size* is −1 (the default) Is the "−" character deliberate in "−1"? I would expected ``-1``.

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Roundup Robot added the comment: New changeset d4fce64b1c65 by Martin Panter in branch 'default': Issue #23214: Remove BufferedReader.read1(-1) workaround https://hg.python.org/cpython/rev/d4fce64b1c65 -- ___ Python tracker

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Roundup Robot added the comment: New changeset b6886ac88e28 by Martin Panter in branch 'default': Issue #23214: Implement optional BufferedReader, BytesIO read1() argument https://hg.python.org/cpython/rev/b6886ac88e28 -- nosy: +python-dev ___ Python

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Martin Panter added the comment: Okay here is a patch implementing read1(-1) in BufferedReader and BytesIO (my original proposal). Other changes: * Changed read1(size=-1) → read1([size]), because BufferedReader and BytesIO do not accept keyword arguments (see also Issue 23738) * Defined

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Antoine Pitrou added the comment: > Define BufferedIOBase.read1(-1) to read and return an arbitrary number > of bytes, more than zero unless none are available due to EOF or > non-blocking mode. Maybe suggest that it would return the current > buffered data or try to read a full buffer of

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Martin Panter added the comment: Calling BufferedReader.read1(sys.maxsize) gives me a MemoryError. Making read1(-1) equivalent to read1(sys.maxsize) only makes sense where the return value already has a predetermined size, and only a limited buffer needs to be allocated. Another

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Serhiy Storchaka added the comment: Shouldn't read1(-1) be the same as read1(sys.maxsize)? I.e. read from a buffer without limit. -- nosy: +benjamin.peterson, pitrou, serhiy.storchaka, stutzbach ___ Python tracker

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Martin Panter added the comment: Looking at this again, I think a less intrusive way forward would be to: * Document that in 3.6, the required signature is now BufferedIOBase.read1(size). An implementation no longer has to provide a default size, and no longer has to accept negative sizes. *

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Martin Panter added the comment: Looking at the test suite: * read1() of LZMAFile and GzipFile (both implementing BufferedIOBase) are asserted to return a non-zero result until EOF * LZMAFile.read1(0) is asserted to return an empty string * BufferedReader.read1(-1) is asserted to raise

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

New submission from Martin Panter: I am trying to make LZMAFile (which implements BufferedIOBase) use a BufferedReader in read mode. However this broke test_lzma.FileTestCase.test_read1_multistream(), which calls read1() with the default size argument. This is because BufferedReader.read1()