Author odd_bloke
Recipients odd_bloke
Date 2017-08-07.03:28:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1502076510.54.0.648446505741.issue31129@psf.upfronthosting.co.za>
In-reply-to
Content
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).
History
Date User Action Args
2017-08-07 03:28:30odd_blokesetrecipients: + odd_bloke
2017-08-07 03:28:30odd_blokesetmessageid: <1502076510.54.0.648446505741.issue31129@psf.upfronthosting.co.za>
2017-08-07 03:28:30odd_blokelinkissue31129 messages
2017-08-07 03:28:29odd_blokecreate