[Waterluvian]

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.

[maweki]

True is the identity of that particular monoid.

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

[zahlman]

>I hit a case where I actually test nothing and have no results. Did I pass?

All your tests passed. After all, none failed, right?

https://en.wikipedia.org/wiki/Vacuous_truth

[Jtsummers]

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.

[ok_dad]

There are no "falsy" elements in an empty list, so `all([])` is `True` based on the description and "equivalent code" in the docs * [0].

[0]: https://docs.python.org/3/library/functions.html#all

* The official docs are pretty good, people should read them more often!

[_a_a_a_]

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).

[happytoexplain]

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.

[_a_a_a_]

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?

[kjeetgill]

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.

[zahlman]

>Just because the problem may be higher up the chain, even up to the design of the system

But it isn't in the system design. It's in the fundamental nature of logic itself.

[pjot]

Since an empty list has no elements, there’s nothing to contradict the condition.

[_a_a_a_]

> I hit a case where I actually test nothing and have no results. Did I pass?

equally, can you reasonably say you failed?