Layman's Guide to Python Built-in Functions
mattlayman.com
mattlayman.com
This is The ultimate clickbait. Bravo!
> 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> 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.
passed = all(test_results)
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.
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
All your tests passed. After all, none failed, right?
If someone wants to consider running zero tests a failure they need to pose the right question for their context.
[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?
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
But it isn't in the system design. It's in the fundamental nature of logic itself.
equally, can you reasonably say you failed?