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

Re:The 2,500 year old history of why Python’s all([]) return... by majewsky on Wednesday March 18, 2020 @05:35AM (#22614937)

  all(xs) and all(ys) == all(xs + ys)

If I understand you correctly, the "and" should be an "implies" instead:

  all(xs) => (all(ys) == all(xs + ys))

Otherwise this law cannot be true since there exist xs for which !all(xs).

[ Parent | on HN ]

Re:The 2,500 year old history of why Python’s all([]) return... by quietbritishjim on Wednesday March 18, 2020 @05:43AM (#22614970)

I think they just got their operator precedences mixed up. They meant:

    (all(xs) and all(ys)) == all(xs + ys)

This is why you should always use parentheses unless it's absolutely obvious! I certainly had to check the docs to find out which way round it goes. I guess normally you're not dealing with Boolean variables so having == bind tighter makes more sense:

    y is not None and x == 7

[ Parent | on HN ]

Re:The 2,500 year old history of why Python’s all([]) return... by eru on Wednesday March 18, 2020 @05:50AM (#22615000)

Yes, indeed! Sorry, I was deviating from the Python order of precedence.

[ Parent | on HN ]