> 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.
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.
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.
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.
This is The ultimate clickbait. Bravo!
reply