> all returns True if all elements in something list-like (such as a list or tuple) are “truthy.” If any element is false or if the list is empty, it returns False.
Python 3.11.2 (main, Aug 26 2024, 07:20:54) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> all([])
True
I get why but I’ll never not see this as a counterintuitive footgun.
Edit: yes I get why. The logic is there. But my brain just can’t help but see the inverse: eg.
passed = all(test_results)
I hit a case where I actually test nothing and have no results. Did I pass?
Because in my brain I’m always framing things with how a loop can be run zero times. A collection of zero elements is not a case I usually have to manually cover.
Edit again: did all of that confuse you? Because I was completely backwards and wrong. It’s time to clock out for the day.
It's a consequence of enforcing logical consistency. You can't get around that (but if you want to suggest other behaviour and justify it, I'd be interested).
This is a frustratingly common reply to "why is this example unintuitive" across software.
Just because the problem may be higher up the chain, even up to the design of the system, doesn't mean it isn't a problem that has real consequences.
E.g. in this case, one possible solution is to not have the concept of "falsy" and "truthy", forcing 'all' to take a mapping closure (which may necessitate other changes, to the point where you now have essentially a completely different language).
It's useful to call these things out every time they trip us up, if not to fix them, then to avoid them next time somebody starts from scratch.
Okay, I'll respond because you made an interesting point, but you've also pissed me off. Let's follow this through: for a start, just because it's an intuitive doesn't mean it's wrong. However, you made me think that may be we can force at compile time that all() must take a non-empty list of Booleans where we can be sure that the problem domain should never have empty lists. I think with modern typing we can do this with dependent types (but I'm not an expert on this, but you have raised an interesting possibility, thanks).
However there are domain cases where empty lists still make sense, so you're still going to have to account for them in a rational way, and that means logically consistent, and I guarantee we will be back to what you don't like. But that's ok.
Now where you've pissed me off is this bit
> n this case, one possible solution is to not have the concept of "falsy" and "truthy"
and
> forcing 'all' to take a mapping closure
Perhaps you could un-piss me off by explaining what the bloody hell those two are supposed to mean – pretend I'm a language designer that interested in your idea (which actually I am) – what are you asking me to implement?
The poster is basically proposing something like always doing:
def all(lis: List[T], mapf: Callable [[T], bool]) -> bool:
for e in (mapf(l) for l in lis):
if e is False: return False
return True
At least that's my take on avoiding Truthy and Falsy via a mapping closure (or function?). But I don't see it solving OPs issue here when lis is empty... So maybe I'm missing something too.
All the tests also failed, because none passed. Both are true but most people only find out all the zero tests passed because that's the question asked.
If someone wants to consider running zero tests a failure they need to pose the right question for their context.
To be honest I hate searching for docs on built-in Python functions. The reference is actually hard to navigate and it seems to spread this information out. Thanks for this.
24 comments
[ 5.4 ms ] story [ 58.8 ms ] thread> all returns True if all elements in something list-like (such as a list or tuple) are “truthy.” If any element is false or if the list is empty, it returns False.
> all([]) returns True since the iterable is empty.
Edit: yes I get why. The logic is there. But my brain just can’t help but see the inverse: eg.
I hit a case where I actually test nothing and have no results. Did I pass?Because in my brain I’m always framing things with how a loop can be run zero times. A collection of zero elements is not a case I usually have to manually cover.
Edit again: did all of that confuse you? Because I was completely backwards and wrong. It’s time to clock out for the day.
[0]: https://docs.python.org/3/library/functions.html#all
* The official docs are pretty good, people should read them more often!
Just because the problem may be higher up the chain, even up to the design of the system, doesn't mean it isn't a problem that has real consequences.
E.g. in this case, one possible solution is to not have the concept of "falsy" and "truthy", forcing 'all' to take a mapping closure (which may necessitate other changes, to the point where you now have essentially a completely different language).
It's useful to call these things out every time they trip us up, if not to fix them, then to avoid them next time somebody starts from scratch.
However there are domain cases where empty lists still make sense, so you're still going to have to account for them in a rational way, and that means logically consistent, and I guarantee we will be back to what you don't like. But that's ok.
Now where you've pissed me off is this bit
> n this case, one possible solution is to not have the concept of "falsy" and "truthy"
and
> forcing 'all' to take a mapping closure
Perhaps you could un-piss me off by explaining what the bloody hell those two are supposed to mean – pretend I'm a language designer that interested in your idea (which actually I am) – what are you asking me to implement?
But it isn't in the system design. It's in the fundamental nature of logic itself.
In other words: if you want all(a++b) == all(a) and all(b) to be true for all lists a,b, then then all([]) needs to be true.
Vice versa for any/or/False
equally, can you reasonably say you failed?
All your tests passed. After all, none failed, right?
https://en.wikipedia.org/wiki/Vacuous_truth
If someone wants to consider running zero tests a failure they need to pose the right question for their context.
This is The ultimate clickbait. Bravo!