On Tue, 14 Apr 2009, Mark Dickinson wrote:
> 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()
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
--
http://mail.python.org/mailman/listinfo/python-list
