3 ms·
Regardless of whether you thing the return value should be True or False, this behavior violates the Principle of Least Astonishment [0] for a significant numbe
by justin_oaks 3y ago
Regardless of whether you thing the return value should be True or False, this behavior violates the Principle of Least Astonishment [0] for a significant number of people.
Such violations in software inevitably lead to bugs that could have been avoided. The real question in my mind isn't what the return value should be. The question is "How can this problem be wholly avoided?"
Some have suggested requiring a default return value when the iterator argument is empty. Others have suggested throwing an error. Perhaps others will suggest the all() function shouldn't exist, although that may be throwing the baby out with the bathwater.
[0] https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
- H8crilA 3y agoWhat's an example realistic problem/piece of code that could be buggy because of this definition of all()?
- justincredible 3y ago[dead]
- kstrauser 3y agoI disagree. If lst = [True, True]; all(lst) is True is True, and lst = [True]; all(lst) is True is True, I'd be very surprised by lst = []; all(lst) is False Basically, all(lst) is the same as `not any(not item for item in lst)`. If we inverted the value of `all([])`, I'd argue that we'd also have to invert the value of `any([])`, which today evaluates as False. `any([]) is True` would be beyond bizarre to me.
- rain1 3y agoThe people that are astonished by this just need to learn why. It's not the function that is wrong, it's those people.