any(), all() and empty iterable

[John O'Hagan]

On Tue, 14 Apr 2009, Mark Dickinson wrote:
> On Apr 14, 7:21 pm, Luis Alberto Zarrabeitia Gomez <ky... at uh.cu>
>
> wrote:
> > It's more than that. Python's following the rules here. Maybe it could be
> > documented better, for those without a background in logic/discrete
> > mathematics, but not changed.
>
> Agreed.
>
> I'd like to guess that in 93.7% of cases, when a programmer
> has used all(seq) without having thought in advance about what the
> right thing to do is when seq is empty, the current behaviour is
> already the right one.  I tried to test this hypothesis, but a
> Google code search for uses of all() turned up very little
> besides definitions.  For example:
>
> if all(t.already_filed() for t in my_tax_forms):
>     go_to_bed_happy()
> else:
>     file_for_extension()


But what about this:
	
if all(evidence):
	suspect_is_guilty
else:
	suspect_is_innocent

:)

[...]

>
> The current definition also makes reasoning about programs and
> program transformations easier, thanks to invariants like:
>
> all(seq1 + seq2) === all(seq1) and all(seq2)
>
> and
>
> all(all(s) for s in seqs) === all(chain(*seqs))
>
> and
>
> any(not s for s in seq) == not all(seq)
>
> These invariants wouldn't hold if all([]) were False, or raised
> an exception.
>
[...]

OK, that's pretty compelling!

Regards,

John