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.
Created on 2017年08月07日 03:28 by odd_bloke, last changed 2022年04月11日 14:58 by admin. This issue is now closed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 3012 | closed | odd_bloke, 2017年08月07日 03:50 | |
| Messages (5) | |||
|---|---|---|---|
| msg299821 - (view) | Author: Daniel Watkins (odd_bloke) * | Date: 2017年08月07日 03:28 | |
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). |
|||
| msg299822 - (view) | Author: R. David Murray (r.david.murray) * (Python committer) | Date: 2017年08月07日 03:41 | |
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. |
|||
| msg299823 - (view) | Author: Guido van Rossum (gvanrossum) * (Python committer) | Date: 2017年08月07日 04:08 | |
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 https://github.com/python/mypy/issues/3805#issuecomment-320561797 |
|||
| msg300254 - (view) | Author: Daniel Watkins (odd_bloke) * | Date: 2017年08月14日 16:39 | |
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 <report@bugs.python.org> wrote: > > Guido van Rossum added the comment: > > 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 > https://github.com/python/mypy/issues/3805#issuecomment-320561797 > > ---------- > nosy: +gvanrossum > > _______________________________________ > Python tracker <report@bugs.python.org> > <http://bugs.python.org/issue31129> > _______________________________________ > |
|||
| msg300255 - (view) | Author: Guido van Rossum (gvanrossum) * (Python committer) | Date: 2017年08月14日 16:44 | |
I don't think this is worth it. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:58:49 | admin | set | github: 75312 |
| 2017年08月14日 16:44:42 | gvanrossum | set | status: open -> closed resolution: wont fix messages: + msg300255 stage: resolved |
| 2017年08月14日 16:39:54 | odd_bloke | set | messages: + msg300254 |
| 2017年08月07日 04:08:53 | gvanrossum | set | nosy:
+ gvanrossum messages: + msg299823 |
| 2017年08月07日 03:50:20 | odd_bloke | set | pull_requests: + pull_request3045 |
| 2017年08月07日 03:42:24 | r.david.murray | set | type: enhancement |
| 2017年08月07日 03:41:51 | r.david.murray | set | nosy:
+ r.david.murray, lukasz.langa messages: + msg299822 |
| 2017年08月07日 03:28:30 | odd_bloke | create | |