On Mon, 20 Apr 2009, Antoon Pardon wrote: > On 2009-04-15, John O'Hagan <m...@johnohagan.com> wrote: > > On Tue, 14 Apr 2009, Mark Dickinson wrote:
[...] > >> 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 > > even if the evidence is not empty, the above wouldn't be > a good test, because you need enough evidence en enough > is not implied by all even if all is more than nothing. One should probably file for an extension until one gets some new tax forms, too, for that matter. It was just a facetious way of suggesting that it could be seen as counter-intuitive to say that no evidence is all true (you trimmed my smiley). >>> evidence=() >>> all(i is True for i in evidence) True >>> all(i is False for i in evidence) True >>> all(i is blue for i in evidence) True However don't worry, I've been thoroughly convinced that this behaviour is the way it is (and should be) done, if for no other reason than that the alternatives are even weirder! John -- http://mail.python.org/mailman/listinfo/python-list
