[Python-ideas] keyword arguments everywhere (stdlib) - issue8706

[Gregory P. Smith]

On Fri, Mar 2, 2012 at 12:00 PM, Guido van Rossum <guido at python.org> wrote:

> I've written such decorators too, but they've got quite a bit of
> overhead...
>
yeah those fall into the gross hacks I alluded to in my original post. ;)

I intentionally decided to leave out discussion of "should we allow
positional-only arguments to be declared in Python" but it is a valid
discussion and thing to consider...

if we go that route, could it be possible to implement range([start=0, ]
stop[, step=1]) such that they are positional only but mutliple arguments
are treated different than strictly sequential without writing conditional
code in Python to figure out each one's meaning at runtime.

speaking of range... I think start and stop are plenty obvious, but I'd
like to allow step to be specified as a keyword.

-gps


>  --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>
>> wrote:
>> >>> +1 on adding keyword arguments to built-in methods and functions
>> where they
>> >>> 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
>>
>>
>> http://code.activestate.com/recipes/521874-functions-with-positional-only-arguments/?in=user-4059385
>>
>> (note that it didn't attract a lot of attention !).  The recipe also
>> refers to the original discussion.
>>
>> --
>> Arnaud
>>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120302/7c2d1c55/attachment.html>