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

[Ron Adam]

On Fri, 2012-03-02 at 18:22 -0800, Raymond Hettinger wrote:
> 
> On Mar 2, 2012, at 2:01 PM, Gregory P. Smith wrote:
> 
> > speaking of range... I think start and stop are plenty obvious, but
> > I'd like to allow step to be specified as a keyword.
> 
> 
> range() has been around 20+ years and this has never been requested.
> In my teaching of Python, it is never arisen as an issue.
> AFAICT, there isn't any code that would be better if step were written
> as a keyword.
> 
> 
> The only expressed motivation for the change is "I'd like" it.
> There should be a higher bar for changing builtins.
> 
> 
> Many of the proposals in this thread are gratuitous and will create
> unnecessary work for other people who have to change anything
> that purports to have a range-like interface, people who have to
> change the other Python implementations, folks who who have 
> to remember which version of Python supports it and which other 
> slice-like functions would also take the argument etc.
> 
> 
> ISTM that having a ton of tiny nit changes to the language
> doesn't make it better.  Instead, effort should be directed
> as substantive changes (better https support, completing xmlrpc, etc).

+1

> Micro rearrangements of the language and a real PITA for folks
> who have to go back-and-forth between different versions of Python.
> So, we should raise the bar to something higher than "I'd like feature
> X"
> and ask for examples of code that would be better or for user requests
> or some actual demonstration of need.  ISTM that 20 years of history
> with range() suggests that no one needs this (nor have I seen a need
> in any other language with functions that take a start/stop/step).

On a more general note...

It seems to me that sometimes the writer of functions wish to have more
control of how the function is called, but I think it is better that the
user of a function can select the calling form that perhaps matches the
data and/or style they are using more closely.

I hope in the future that we find ways to simplify function signatures
in a way that make them both easier to use and more efficient for the
function user, rather than continue adding specific little tweaks that
give the function designer more control over how the function user calls
it.

My 2cents,
   Ron