[Python-ideas] keyword arguments everywhere (stdlib) - issue8706
Guido van Rossum
guido at python.org
Fri Mar 2 21:00:14 CET 2012
I've written such decorators too, but they've got quite a bit of overhead...
--Guido van Rossum (sent from Android phone)
On Mar 2, 2012 11:43 AM, "Arnaud Delobelle" <arnodel at gmail.com> wrote:
> On 2 March 2012 19:28, Guido van Rossum <guido at python.org> wrote:
> > On Fri, Mar 2, 2012 at 4:13 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >> On Fri, Mar 2, 2012 at 6:43 PM, Steven D'Aprano <steve at pearwood.info>
> >>> +1 on adding keyword arguments to built-in methods and functions where
> >>> would help readability, e.g str.find(c, start=23), even if this
> happens in a
> >>> ad-hoc fashion.
> >> Indeed, this is the approach we have taken to date. For example,
> >> str.split() recently gained keyword support for 3.3 because
> >> "text.split(maxsplit=1)" is less cryptic than "text.split(None, 1)".
> >> It makes the most sense when at least one of the following holds:
> >> - the second argument accepts a number that is unclear if you're not
> >> familiar with the full function signature
> >> - the earlier arguments have sensible default values that you'd prefer
> >> not to override
> >> So +1 on declaring "make X support keyword arguments"
> >> non-controversial for multi-argument functions, +0 on also doing so
> >> for single argument functions, but -0 on attempting to boil the ocean
> >> and fix them wholesale.
> > Hm. I think for many (most?) 1-arg and selected 2-arg functions (and
> > rarely 3+-arg functions) this would reduce readability, as the example
> > of ord(char=x) showed.
> > I would actually like to see a syntactic feature to state that an
> > argument *cannot* be given as a keyword argument (just as we already
> > added syntax to state that it *must* be a keyword).
> There was a discussion about this on this list in 2007. I wrote some
> decorators to implement it this functionality. Here's one at
> (note that it didn't attract a lot of attention !). The recipe also
> refers to the original discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas