On Apr 14, 7:21 pm, Luis Alberto Zarrabeitia Gomez <ky...@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()
In the event that you didn't have any tax_forms, this
does the right thing.
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.
IMO, the current behaviour meets both the practicality *and*
the purity criteria.
Mark
--
http://mail.python.org/mailman/listinfo/python-list
