The parameters for io.[Text]IOBase.seek are currently positional only, as discussed in http://bugs.python.org/issue25030.

We make the parameters to be both positional and keyword based.

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: file.seek(whence=SEEK_CUR, 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(file.seek, whence=SEEK_CUR)(offset)

Also, making the offset default to zero might be useful for doing file.seek(whence=SEEK_END).

If we do go ahead with this, it would need documenting (version changed note), and test cases.

You've listed much of the benefits it can bring about.

The real problem is there are many places like iobase.seek 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.

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.