Making min and max behave more like any and all
I just had something pointed out to me in #python that min and max accept *args, I know for a fact that any and all only use a single iterable password. Shouldn't we allow either one of the two ideas? Either max/min take only iterable arguments. OR Allow any/all to use *args In the second case this becomes legal any(1 in a, 2 in b, 3 in c) In the first case this becomes illegal max(1,2,3,4,5)
On Wed, Nov 30, 2011 at 7:30 PM, Jakob Bowyer <jkbbwr@gmail.com> wrote:
I just had something pointed out to me in #python that min and max accept *args, I know for a fact that any and all only use a single iterable password. Shouldn't we allow either one of the two ideas?
any(True, False, True) all(False, True, True) max(1,2,3,4) min(1,2,3,4) sum(1,2,3,4) list(1,2,3,4) set(1,2,3,4) TOOWTDI would mean to allow only one argument in all of the above. Currently only max/min break the rule. I'm +1 for making python consistent. And specifically would be +0 for allowing it all. --Yuval Btw even enumerate could have been a candidate though it already has a second argument.
On Nov 30, 2011 5:31 PM, "Jakob Bowyer" <jkbbwr@gmail.com> wrote:
I just had something pointed out to me in #python that min and max accept
*args, I know for a fact that any and all only use a single iterable password.
Shouldn't we allow either one of the two ideas?
Either max/min take only iterable arguments. OR Allow any/all to use *args
In the second case this becomes legal
any(1 in a, 2 in b, 3 in c)
I'd use 'or' here. For all, I'd use 'and'. -- Arnaud
On Wed, Nov 30, 2011 at 9:30 AM, Jakob Bowyer <jkbbwr@gmail.com> wrote:
I just had something pointed out to me in #python that min and max accept *args, I know for a fact that any and all only use a single iterable password. Shouldn't we allow either one of the two ideas?
Either max/min take only iterable arguments. OR Allow any/all to use *args
This seems consistency for consistency's sake, not for any particularly good reason. min/max are quite different from any/all, e.g. min() or max() without arguments makes no sense, while any() / all() on an empty list has a perfectly fine meaning (False / True, respectively). In the second case this becomes legal
any(1 in a, 2 in b, 3 in c)
But that's just alternative syntax for 1 in a or 2 in b or 3 in c except that it doesn't have shortcut semantics, so it would be an attractive nuisance. Note that any() / all() *do* have shortcut semantics, in the sense that they stop iterating over the argument iterable as soon as they have an answer that forces the outcome (True in the case of any(), False in the case of all()). This doesn't apply to min() or max() -- you always have to look at all values before you can decide on which is the largest. (It would be different if we had a general infinity, but we don't -- only floating point numbers support infinity).
In the first case this becomes illegal max(1,2,3,4,5)
Which I presume is rarely needed but if necessary can easily be written as max((1, 2, 3, 4, 5)). -- --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
On 2011-11-30, at 19:15 , Guido van Rossum wrote:
In the first case this becomes illegal max(1,2,3,4,5)
Which I presume is rarely needed but if necessary can easily be written as max((1, 2, 3, 4, 5)). The *args form is rather nice for the (pretty common I'd think) task of min/maxing a pair of values, one know (default) and one unknown for instance.
It is also a common interface for min/max functions.
On Wed, Nov 30, 2011 at 10:22 AM, Masklinn <masklinn@masklinn.net> wrote:
On 2011-11-30, at 19:15 , Guido van Rossum wrote:
In the first case this becomes illegal max(1,2,3,4,5)
Which I presume is rarely needed but if necessary can easily be written as max((1, 2, 3, 4, 5)). The *args form is rather nice for the (pretty common I'd think) task of min/maxing a pair of values, one know (default) and one unknown for instance.
It is also a common interface for min/max functions.
Of course. IMO the status quo is optimal -- max(a, b) is very useful. Not so for any(a, b) though. -- --Guido van Rossum (python.org/~guido)
participants (5)
-
Arnaud Delobelle
-
Guido van Rossum
-
Jakob Bowyer
-
Masklinn
-
Yuval Greenfield