Repository navigation
RawConfigParser.items() is unusual in taking arguments #75312
Description
| BPO | 31129 |
|---|---|
| Nosy | @gvanrossum, @OddBloke, @bitdancer, @ambv |
| PRs |
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 2017-08-14.16:44:42.167>
created_at = <Date 2017-08-07.03:28:30.450>
labels = ['3.7', 'type-feature', 'library']
title = 'RawConfigParser.items() is unusual in taking arguments'
updated_at = <Date 2017-08-14.16:44:42.166>
user = 'https://github.com/OddBloke'bugs.python.org fields:
activity = <Date 2017-08-14.16:44:42.166>
actor = 'gvanrossum'
assignee = 'none'
closed = True
closed_date = <Date 2017-08-14.16:44:42.167>
closer = 'gvanrossum'
components = ['Library (Lib)']
creation = <Date 2017-08-07.03:28:30.450>
creator = 'odd_bloke'
dependencies = []
files = []
hgrepos = []
issue_num = 31129
keywords = []
message_count = 5.0
messages = ['299821', '299822', '299823', '300254', '300255']
nosy_count = 4.0
nosy_names = ['gvanrossum', 'odd_bloke', 'r.david.murray', 'lukasz.langa']
pr_nums = ['3012']
priority = 'normal'
resolution = 'wont fix'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue31129'
versions = ['Python 3.7']
Activity
OddBloke commentedon Aug 7, 2017
A grep through the codebase shows that RawConfigParser.items() is the only .items() method in the stdlib which accepts arguments.
This is annoying as a stdlib user because when I see the arguments being passed to RawConfigParser.items(), I have _no idea_ what they do. Instinctively, I do not expect .items() to take arguments, and I have to go and work out what it does each time.
I think it would be both easier to understand, and more consistent with general Pythonic practice, if the two codepaths in RawConfigParser.items() were split in to separate methods; one which takes no arguments (which will continue to behave as it does today when called that way) and one which is named in a way that makes it clearer what it does (and takes arguments).
bitdancer commentedon Aug 7, 2017
For backward compatibility reasons this will not be changed. I don't know if the idea of adding a method and doing a documentation deprecation is worth it or not.
gvanrossum commentedon Aug 7, 2017
I think the proposed change is not worth it. Developments in type checking (in particular overloading) make it unambiguous what the return type will be from just a static inspection of the call site. (Given that the _UNSET value is intended to be private.) See also python/mypy#3805 (comment)
OddBloke commentedon Aug 14, 2017
Having ironed out my confusion over typing the method, I agree that making
the types more obvious is not a compelling argument for this change.
That said, I think the current API has been confusing to me in the past,
and I think the proposed change is still a worthwhile improvement for users
of this module.
On Mon, Aug 7, 2017 at 12:08 AM Guido van Rossum <[email protected]>
wrote:
gvanrossum commentedon Aug 14, 2017
I don't think this is worth it.