On: The 2,500 year old history of why Python’s all([]) returns True

[gridlockd]

It probably is because you studied mathematics.

If you think of "all" as "in this set, no element exists which is False" then it is "obviously" the right behavior.

However, consider this more practical example:

    x = {1,2,3}
    y = {}

    all(e in x for e in y)
    > True

This doesn't strike me as obviously right.

[yorwba → gridlockd]

That's mathematically equivalent to "y is a subset of x", which is obviously right. (Except for the wrinkle that y is a dict, not a set.)

[_v7gu → yorwba]

Replying to the sibling comment,

We invented mathematics because practical thinking leaves us without answers at some points. You are free to axiomatically choose "all([]) = false", but then you'll find out that many mathematical equivalences won't hold as they all assume only the ZF axioms.

[gridlockd → yorwba]

I don't disagree. Try to mute your "mathematical thinking" for a second and read it as an ordinary person, with a focus on practicality. It just doesn't look right.

If it did look right to me, I wouldn't be sitting here typing this all out. I would be silently agreeing with the mathematical point of view.

That's what tells me this is a likely source of confusion and error.

[umanwizard → gridlockd]

I simply don’t have the intuition, at all, no matter how I think about it, that it should be false.

Is there any language that works the way you’re suggesting is more practical/intuitive?

[gridlockd → umanwizard]

I'm not saying it should be false. It's the law of the excluded middle that forces us to make a true/false decision, in which case I can agree that, for mathematical reasons, it should be true.

For practical reasons, it might be better for it to be false. That would require some empirical research on whether this could actually prevent harmful behavior in practice.

From a design perspective, I would argue that "all" should not be defined for empty lists, because that forces people to consider whether the often-forgotten "empty list" edge case might cause an issue.

[nicoburns → gridlockd]

It's the right choice for practical reasons as well as theoretical/mathematical ones. It means that you generally don't have to special case the empty list case, you can just run let it happily do nothing. If you want exceptional behavior then you should probably use some other value (e.g. None)

[gridlockd → nicoburns]

> It means that you generally don't have to special case the empty list case, you can just run let it happily do nothing.

The consequence of "if (True)" is usually to do something, not nothing. The consequence of doing something by overlooking the "empty list" special case may be harmful.

Preventing potential harm is more important than not having the programmer jump through a couple of extra hoops to account for the special case. That makes the special case impossible to overlook.

This kind of reasoning is generally accepted when talking about implicitly nullable types vs explicitly nullable types (optional types), but somehow in this context people are more stubborn.

[eru → gridlockd]

> This kind of reasoning is generally accepted when talking about implicitly nullable types vs explicitly nullable types (optional types), but somehow in this context people are more stubborn.

Not sure that's the same? Haskell has no implicitly nullable types. Everything not explicitly marked as optional is non-nullable.

But still, if your algorithm at hand can treat nulls the same as non-nulls, it's a good idea to do so. (Eg in a sorting algorithm where you just feed the elements to the user supplied comparison function, and let that function handle comparing of optional elements.)

[int_19h → gridlockd]

Can you give a practical example of a case where that answer would actually be wrong for an empty set, though? Like, what are you trying to check, and what would be inside the "if"?