Steve R. Hastings wrote:
> I'm completely on board with the semantics for any(). But all() bothers
> me. If all() receives an empty list, it will return True, and I don't
> like that. To me, all() should be a more restrictive function than any(),
> and it bothers me to see a case where any() returns False but all()
> returns True.
Perhaps a practical example will illustrate why all() returns False
better than all this mathematical mumbo-jumbo.
Ok, say you're writing a simple software management/bug tracking
system. It manage another software package that is to have periodic
releases, but the release can only be made when there are no
outstanding bugs. You might have a line of code that looks like this:
if all(bug.status == 'closed' for bug in bugs_filed):
do_release()
As you can see, the release will only happen if all the bugs are marked
closed. But... what if no bugs have been filed? If all() were to
return False on an empty sequence, the software couldn't be fixed until
at least one bug had been filed and closed!
The point is, whenever you have to test that every item in a list is
true, it is almost always correct for the test to pass when the list is
empty. The behavior of all() is correct.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
