Re: [Python-ideas] "any" and "all" support multiple arguments

[Neil Girdhar]

On Tuesday, August 1, 2017 at 12:58:24 PM UTC-4, Clément Pit-Claudel wrote:
>
> On 2017-08-01 17:28, Nick Coghlan wrote:
> > Right, the main correspondence here is with "sum()": folks can't write
> > "sum(a, b, c)", but they can write "a + b + c".
> > 
> > The various container constructors are also consistent in only taking
> > an iterable, with multiple explicit items being expected to use the
> > syntactic forms (e.g. [a, b, c], {a, b, c}, (a, b, c))
> > 
> > The same rationale holds for any() and all(): supporting multiple
> > positional arguments would be redundant with the existing binary
> > operator syntax, with no clear reason to ever prefer one option over
> > the other.
>
> Isn't there a difference, though, insofar as we don't have a '+/sum' or 
> 'and/all' equivalent of [a, b, *c]?
> You need to write 1 + 3 + sum(xs), or a and b and all(ys).  Or, of course, 
> any(chain([a], [b], c)), but that is not pretty.
>

a or b or any(c)

seems clear to me.
 

> Clément.
> ___
> Python-ideas mailing list
> python...@python.org 
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "any" and "all" support multiple arguments

[Terry Reedy]

On 8/1/2017 9:01 AM, Louie Lu wrote:

Hi all,

In "min" and "max" builtin-func, it support two style of args:

 min(...)
 min(iterable, *[, default=obj, key=func]) -> value
 min(arg1, arg2, *args, *[, key=func]) -> value


To me, two APIs is a nuisance.  For one thing, default has to be keyword 
only and not just optional.  Compare with sum:


>>> sum((2,3,4),5)
14

>>> min((2,3,4),5)  # Py3
Traceback (most recent call last):
  File "", line 1, in 
min((2,3,4),5)
TypeError: '<' not supported between instances of 'int' and 'tuple'

>>> min((2,3,4),5)  # Py2
5
>>> min(5, (2,3,4))
5

I believe that a version of the second was in original Python (and at 
least in 1.3) whereas the first was added later, likely with the new 
iterator protocol (2.2).  In any case,  with *unpacking in displays, the 
second is no longer needed.


>>> min(4,3, *[1,2])
1
>>> min((4,3, *[1,2]))
1

If I am correct, perhaps the doc for max and min in 
https://docs.python.org/3/library/functions.html#max
should mention that the 2nd is derived from the original syntax, kept 
for back compatibility (rather than a new innovation, to be imitated).


I would rather get rid of the exceptional case than emulate it.


But for "any" and "all", it only support iterable:

 all(iterable, /)
 Return True if bool(x) is True for all values x in the iterable.


As Nick pointed out, this is standard now.

>>> list((1,2,3))
[1, 2, 3]
>>> list(1,2,3)
Traceback (most recent call last):
  File "", line 1, in 
list(1,2,3)
TypeError: list() takes at most 1 argument (3 given)

--
Terry Jan Reedy

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "any" and "all" support multiple arguments

[Lucas Wiman]

On Tue, Aug 1, 2017 at 6:01 AM, Louie Lu  wrote:

> [...]
> I'm not sure if this is discuss before, but can "any" and "all"
> support like min_max "arg1, arg2, *args" style?
>

Can this be done consistently? For example consider x=[[]]. Then all(x)
where x is interpreted as an iterable should be False, but all(x) where x
is interpreted as a single argument should be True. This inconsistency
already exists for max:

>>> max({1, 2})
2
>>> max({1, 2}, {1})
set([1, 2])

However, it doesn't seem like there's a good reason to add an inconsistency
to the API for any/all.

- Lucas
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "any" and "all" support multiple arguments

[Clément Pit-Claudel]

On 2017-08-01 17:28, Nick Coghlan wrote:
> Right, the main correspondence here is with "sum()": folks can't write
> "sum(a, b, c)", but they can write "a + b + c".
> 
> The various container constructors are also consistent in only taking
> an iterable, with multiple explicit items being expected to use the
> syntactic forms (e.g. [a, b, c], {a, b, c}, (a, b, c))
> 
> The same rationale holds for any() and all(): supporting multiple
> positional arguments would be redundant with the existing binary
> operator syntax, with no clear reason to ever prefer one option over
> the other.

Isn't there a difference, though, insofar as we don't have a '+/sum' or 
'and/all' equivalent of [a, b, *c]?
You need to write 1 + 3 + sum(xs), or a and b and all(ys).  Or, of course, 
any(chain([a], [b], c)), but that is not pretty.

Clément.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "any" and "all" support multiple arguments

[Nick Coghlan]

On 1 August 2017 at 23:24, Paul Moore  wrote:
> On 1 August 2017 at 14:01, Louie Lu  wrote:
>> I'm not sure if this is discuss before, but can "any" and "all"
>> support like min_max "arg1, arg2, *args" style?
>
> I don't see any particular reason why not, but is there a specific use
> case for this or is it just a matter of consistency? Unlike max and
> min, we already have operators in this case (and/or). I'd imagine that
> if I had a use for any(a, b, c) I'd write it as a or b or c, and for
> all(a, b, c) I'd write a and b and c.

Right, the main correspondence here is with "sum()": folks can't write
"sum(a, b, c)", but they can write "a + b + c".

The various container constructors are also consistent in only taking
an iterable, with multiple explicit items being expected to use the
syntactic forms (e.g. [a, b, c], {a, b, c}, (a, b, c))

The same rationale holds for any() and all(): supporting multiple
positional arguments would be redundant with the existing binary
operator syntax, with no clear reason to ever prefer one option over
the other.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "any" and "all" support multiple arguments

[Nick Coghlan]

On 1 August 2017 at 23:43, Ned Batchelder  wrote:
> I find it frustrating that they always return booleans.  It would be more
> useful if any() returned the first true value it finds.  This seems like a
> backward-compatible-enough change to me... :)

While I'm not sure how to interpret that smiley, I figure it's worth
making it explicit that this is decidedly *not* true given
type-dependent serialisation protocols like JSON:

>>> import json
>>> class MyClass:
... def __bool__(self):
... return True
...
>>> json.dumps(any([MyClass()]))
'true'
>>> json.dumps(MyClass())
Traceback (most recent call last):
  ...
TypeError: Object of type 'MyClass' is not JSON serializable

The idea of elevating first_true from its current status as an
itertools recipe to actually being an itertools module API has
certainly come up before, though.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "any" and "all" support multiple arguments

[Ned Batchelder]

I find it frustrating that they always return booleans.  It would be
more useful if any() returned the first true value it finds.  This seems
like a backward-compatible-enough change to me... :)

--Ned.


On 8/1/17 9:32 AM, Markus Meskanen wrote:
> I'd be more interested in supporting the "key" function:
>
> any(users, key=User.is_admin)
>
> As opposed to:
>
> any(user.is_admin() for user in users)
>
> 1.8.2017 16.07 "Louie Lu" > kirjoitti:
>
> Hi all,
>
> In "min" and "max" builtin-func, it support two style of args:
>
> min(...)
> min(iterable, *[, default=obj, key=func]) -> value
> min(arg1, arg2, *args, *[, key=func]) -> value
>
> But for "any" and "all", it only support iterable:
>
> all(iterable, /)
> Return True if bool(x) is True for all values x in the
> iterable.
>
>
> I'm not sure if this is discuss before, but can "any" and "all"
> support like min_max "arg1, arg2, *args" style?
>
>
> Thanks,
> Louie.
> ___
> Python-ideas mailing list
> Python-ideas@python.org 
> https://mail.python.org/mailman/listinfo/python-ideas
> 
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
>
>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "any" and "all" support multiple arguments

[Markus Meskanen]

I'd be more interested in supporting the "key" function:

any(users, key=User.is_admin)

As opposed to:

any(user.is_admin() for user in users)

1.8.2017 16.07 "Louie Lu"  kirjoitti:

Hi all,

In "min" and "max" builtin-func, it support two style of args:

min(...)
min(iterable, *[, default=obj, key=func]) -> value
min(arg1, arg2, *args, *[, key=func]) -> value

But for "any" and "all", it only support iterable:

all(iterable, /)
Return True if bool(x) is True for all values x in the iterable.


I'm not sure if this is discuss before, but can "any" and "all"
support like min_max "arg1, arg2, *args" style?


Thanks,
Louie.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "any" and "all" support multiple arguments

[Paul Moore]

On 1 August 2017 at 14:01, Louie Lu  wrote:
> I'm not sure if this is discuss before, but can "any" and "all"
> support like min_max "arg1, arg2, *args" style?

I don't see any particular reason why not, but is there a specific use
case for this or is it just a matter of consistency? Unlike max and
min, we already have operators in this case (and/or). I'd imagine that
if I had a use for any(a, b, c) I'd write it as a or b or c, and for
all(a, b, c) I'd write a and b and c.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] "any" and "all" support multiple arguments

[Louie Lu]

Hi all,

In "min" and "max" builtin-func, it support two style of args:

min(...)
min(iterable, *[, default=obj, key=func]) -> value
min(arg1, arg2, *args, *[, key=func]) -> value

But for "any" and "all", it only support iterable:

all(iterable, /)
Return True if bool(x) is True for all values x in the iterable.


I'm not sure if this is discuss before, but can "any" and "all"
support like min_max "arg1, arg2, *args" style?


Thanks,
Louie.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/