Repository navigation
Make parameter of io.base to be positional and keyword #69243
Description
| BPO | 25057 |
|---|---|
| Nosy | @ezio-melotti, @berkerpeksag, @vadmium |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2015-09-20.05:41:22.312>
created_at = <Date 2015-09-10.14:31:56.821>
labels = ['type-feature']
title = 'Make parameter of io.base to be positional and keyword'
updated_at = <Date 2015-09-20.05:41:22.311>
user = 'https://bugs.python.org/introom'bugs.python.org fields:
activity = <Date 2015-09-20.05:41:22.311>
actor = 'martin.panter'
assignee = 'none'
closed = True
closed_date = <Date 2015-09-20.05:41:22.312>
closer = 'martin.panter'
components = []
creation = <Date 2015-09-10.14:31:56.821>
creator = 'introom'
dependencies = []
files = ['40427']
hgrepos = []
issue_num = 25057
keywords = ['patch']
message_count = 4.0
messages = ['250382', '250428', '250453', '251144']
nosy_count = 4.0
nosy_names = ['ezio.melotti', 'berker.peksag', 'martin.panter', 'introom']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue25057'
versions = ['Python 3.6']
Activity
introom commentedon Sep 10, 2015
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.
vadmium commentedon Sep 10, 2015
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 bpo-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.
introom commentedon Sep 11, 2015
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 bpo-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.
vadmium commentedon Sep 20, 2015
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:
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.