This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Make parameter of io.base to be positional and keyword
Type: enhancement Stage:
Components: Versions: Python 3.6
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: berker.peksag, ezio.melotti, introom, martin.panter
Priority: normal Keywords: patch

Created on 2015-09-10 14:31 by introom, last changed 2022-04-11 14:58 by admin. This issue is now closed.

File name Uploaded Description Edit
patch.diff introom, 2015-09-10 14:31 review
Messages (4)
msg250382 - (view) Author: (introom) * Date: 2015-09-10 14:31
The parameters for io.[Text] are currently positional only, as discussed in

We make the parameters to be both positional and keyword based.
msg250428 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-09-10 23:18
I’m not sure this is a good idea. IOBase is a base class, so adding to its API really means everybody’s subclasses may need to be updated to support the proper keyword argument names. Even ignoring classes outside Python’s standard library, it looks like you would need to update BufferedReader, FileIO, etc.

What is the reason you want to add keyword argument support? See also Issue 8706 about doing this in general to other functions. I can think of one or two weak reasons why this might be useful:

* It allows swapping the arguments:, offset=+4) may be slightly more readable, because the offset has to be interpreted in the context of “whence”.

* It could allow usage like functools.partial(, whence=SEEK_CUR)(offset)

Also, making the offset default to zero might be useful for doing

If we do go ahead with this, it would need documenting (version changed note), and test cases.
msg250453 - (view) Author: (introom) * Date: 2015-09-11 08:36
You've listed much of the benefits it can bring about.

The real problem is there are many places like to modify
to support keyword argument, and seems not many people think it's a
good idea to do that, per issue 8706. But I think the former is the
main hinder. If there is one commiter that is interested to merge in
the related code, I might consider taking my time and handling the
rest related similar functions, including the test and the doc.
msg251144 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-09-20 05:41
For an illustration of the problem that this would cause, I did a quick search through Python’s own source tree. It already has various keyword names:

def seek(self, pos, whence=0):
def seek(self, cookie, whence=0):
def seek(self, offset, whence=0):
def seek(self, position, whence=io.SEEK_SET):

It is easy to imagine third party implementations also exist with a variety of keyword names. So I definitely think we should avoid changing the IOBase API because it will break backwards compatibility. And I think there is no good reason to add explicit keyword support to individual concrete classes like TextIOWrapper, in case it gives users the wrong impression about the general IOBase API.
Date User Action Args
2022-04-11 14:58:20adminsetgithub: 69243
2015-09-20 05:41:22martin.pantersetstatus: open -> closed
resolution: rejected
messages: + msg251144
2015-09-11 08:36:25introomsetmessages: + msg250453
2015-09-10 23:18:25martin.pantersetnosy: + martin.panter
messages: + msg250428
2015-09-10 14:31:56introomcreate