Hi folk,
I stumbled upon the builtin reduce function. It has an optional parameter initial, however if trying to set it like
import operator as op reduce(op.add, range(10), initial=0)
I get
TypeError: reduce() takes no keyword arguments
I think it would be really straightforward to also add keyword possibilities, at least to the parameter initial.
What do you think? best, Stephan
On Fri, Oct 10, 2014 at 8:11 PM, Stephan Sahm Stephan.Sahm@gmx.de wrote:
I stumbled upon the builtin reduce function. It has an optional parameter initial, however if trying to set it like
import operator as op reduce(op.add, range(10), initial=0)
I get
TypeError: reduce() takes no keyword arguments
I think it would be really straightforward to also add keyword possibilities, at least to the parameter initial.
The first thing to note is that reduce(), in Python 3, is now imported from functools; if you're working with Python 2, you won't see this changed unless you can convince people that this is a bug to be fixed. However, prefixing your code with "from functools import reduce" produces the exact same result in Python 3.
The question is, though: What's the advantage? The first two arguments are mandatory, and there's only one optional argument. Do you need to say "initial=" on that?
ChrisA
On 10 Oct 2014 20:07, "Chris Angelico" rosuav@gmail.com wrote:
On Fri, Oct 10, 2014 at 8:11 PM, Stephan Sahm Stephan.Sahm@gmx.de wrote:
I stumbled upon the builtin reduce function. It has an optional
parameter
initial, however if trying to set it like
import operator as op reduce(op.add, range(10), initial=0)
I get
TypeError: reduce() takes no keyword arguments
I think it would be really straightforward to also add keyword possibilities, at least to the parameter initial.
The first thing to note is that reduce(), in Python 3, is now imported from functools; if you're working with Python 2, you won't see this changed unless you can convince people that this is a bug to be fixed. However, prefixing your code with "from functools import reduce" produces the exact same result in Python 3.
The question is, though: What's the advantage? The first two arguments are mandatory, and there's only one optional argument. Do you need to say "initial=" on that?
Converting functools to argument clinic for 3.5 should fix it. I don't believe anyone has tackled that yet.
Cheers, Nick.
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Fri, Oct 10, 2014 at 11:11:36AM +0200, Stephan Sahm wrote:
Hi folk,
I stumbled upon the builtin reduce function. It has an optional parameter initial, however if trying to set it like
import operator as op reduce(op.add, range(10), initial=0)
I get
TypeError: reduce() takes no keyword arguments
I think it would be really straightforward to also add keyword possibilities, at least to the parameter initial.
Unfortunately, this is a limitation of many built-in functions and methods, possibly the majority. E.g.:
Help on built-in function getattr in module builtins: getattr(...) getattr(object, name[, default]) -> value
but:
py> getattr(None, name='spam', default=42) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: getattr() takes no keyword arguments
I seem to recall that there was a reason for this, but I don't quite remember what... searching the archives may give a clue.
Personally, I have no objections *in principle* to adding support for keyword arguments to built-ins, but it will depend on the details of why they weren't already supported.
Steven D'Aprano schrieb am 10.10.2014 um 12:10:
Personally, I have no objections *in principle* to adding support for keyword arguments to built-ins, but it will depend on the details of why they weren't already supported.
There was a major move towards proper argument parsing for builtins and C implemented stdlib modules in Py3.4, but it's still not finished (as this example shows). AFAICT, help is always appreciated on python-dev side.
Stefan
* Steven D'Aprano steve@pearwood.info [2014-10-10 21:10:10 +1100]:
On Fri, Oct 10, 2014 at 11:11:36AM +0200, Stephan Sahm wrote:
Hi folk,
I stumbled upon the builtin reduce function. It has an optional parameter initial, however if trying to set it like
import operator as op reduce(op.add, range(10), initial=0)
I get
TypeError: reduce() takes no keyword arguments
I think it would be really straightforward to also add keyword possibilities, at least to the parameter initial.
Unfortunately, this is a limitation of many built-in functions and methods, possibly the majority. E.g.:
Help on built-in function getattr in module builtins: getattr(...) getattr(object, name[, default]) -> value
but:
py> getattr(None, name='spam', default=42) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: getattr() takes no keyword arguments
I seem to recall that there was a reason for this, but I don't quite remember what... searching the archives may give a clue.
Personally, I have no objections *in principle* to adding support for keyword arguments to built-ins, but it will depend on the details of why they weren't already supported.
FWIW, I'd also really like to see keyword arguments for these builtins. I always have to keep myself from doing things like
"foo bar baz".split(count=1)
But as said, I suspect there is *some* reason this is not possible.
Florian
Florian Bruhin schrieb am 10.10.2014 um 13:05:
FWIW, I'd also really like to see keyword arguments for these builtins. I always have to keep myself from doing things like
"foo bar baz".split(count=1)
But as said, I suspect there is *some* reason this is not possible.
You only have to use the right argument name (and Py3.4):
>>> "abc def".split(maxsplit=1) ['abc', 'def']
Stefan
* Stefan Behnel stefan_ml@behnel.de [2014-10-10 13:29:51 +0200]:
Florian Bruhin schrieb am 10.10.2014 um 13:05:
FWIW, I'd also really like to see keyword arguments for these builtins. I always have to keep myself from doing things like
"foo bar baz".split(count=1)
But as said, I suspect there is *some* reason this is not possible.
You only have to use the right argument name (and Py3.4):
>>> "abc def".split(maxsplit=1) ['abc', 'def']
Stefan
Oh, thanks for the heads-up!
The name was from memory, and I guess the last time I tested this was with 3.3.
Florian
On 10 Oct 2014 21:07, "Florian Bruhin" me@the-compiler.org wrote:
FWIW, I'd also really like to see keyword arguments for these builtins. I always have to keep myself from doing things like
"foo bar baz".split(count=1)
But as said, I suspect there is *some* reason this is not possible.
The technical reason is that many older CPython functions written in C use PyArg_ParseTuple, which only supports positional arguments.
When there's a concrete readability gain from adding keyword argument support to a particular function, patches will often be accepted.
Switching to argument clinic also offers improved introspection support, so that can be a good way to pursue the enhancement.
Regards, Nick.
Florian
-- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/