def all(L):
for i in L:
if not L:
return False
return True
Seems quite clear when presented that way. Same with `any`.
> In logic, this is called the principle of bivalence: there are only two values that a proposition can have, true or false. But Python has None, many other programming languages have null or nil, and Zen has mu. Maybe adding another value would help?
If `all` were in Python v1 it would have thrown an exception when called with an empty list. (Said jokingly, or is it?)
Yes, that's an implementation of all() that produces the current result.
What the article explains is why the thing that produces the current result has the name “all()”.
While both can be answers to different senses of “Why does all() behave the way it does?”, they are fundamentally answers to very different questions that English, being ambiguous in the way natural language tends to be, allows to be expressed in the same words, the implementation explanation is not a clearer answer to the same question answered by the examination of the history of philosophy and predicate logic, and presenting it as if it were is fundamentally misunderstanding the question being answered by the longer piece.
This is the essence of the issue. All the pontification about (sigh) periods of western logic is missing the point.
The object isn't question isn't a statement of philosophical logic[1]. It's a computer program. And, yeah, it's implemented by iterating over the list and returning false if it finds anything false. If it gets to the end, it returns true. And that is all that needs to be said, because it is an algorithm and not a statement about the world. Maybe it's wrong. In which case, file a bug. But the bug isn't about philosophy either, it's about "I want to solve a problem and all() is giving me the wrong answer".
[1] Not to be confused with actual mathematics, of course. Math doesn't have semantic arguments like this because it starts from a stance of defining terms and axioms such that no one gets confused over words. Sigh, again.
This and the parent are mistaking the "how" all([]) is True for the why. The code is the "how", but it doesn't just exist. It could just as easily end in
return len(L) > 0
instead, which would obviously have different behavior. The code is the embodiment of a particular design, the "why", which has a more complex history.
There's no treatment about any "complex history of the design of all()" though. The article is a bunch of nattering about philosophical semantics.
And I'm saying that's just plain dumb. This is an engineering discipline. If there's a "why", then the author of the code is the resource, not (sigh) philosophers. Go ask Guido, or check the commit messages. Don't ask Aristotle, he can't hack.
And the proof (that's right, proof) that I'm right is this: imagine Guido (or whoever) had indeed chosen the opposite convention for all(). It's easy to imagine. And it's equally easy to imagine people getting confused about it and asking about it. And you could reply with exactly this same article trying to explain the "why" behind it as part of two traditions of philosophy.
That's right: the same words explain the opposite convention too. That's not an explanation for "why", is it? This whole discussion is QUITE LITERALLY providing zero insight into the question you're imagining it's answering! It's like asking someone "Why did you paint your house blue?", and them answering "Well, you see, I could have painted it blue, or red."
"All" as the way it is _because_ it's an implementation of the following logical statement:
For all x in X, P(x)
It's not arbitrary, and understanding formal logic and the history of formal logic is a good basis for understanding a great many things in computer science.
And I sigh for a third time. This is emphatically not about "formal logic", it's philosophy. If you want to argue from programming language type theory about the best/right/proper/whatever way to implement set theoretic predicates in python, I'm here for it. If you want to do it by citing Aristotle, my eyes start rolling.
> In logic, this is called the principle of bivalence: there are only two values that a proposition can have, true or false. But Python has None, many other programming languages have null or nil, and Zen has mu. Maybe adding another value would help?
If `all` were in Python v1 it would have thrown an exception when called with an empty list. (Said jokingly, or is it?)