26 ms·

That's an interesting point, but I'm inclined to say that very few languages could come up with {1:this} - Prolog could, I think - and that running into those e

by sesqu 13y ago

That's an interesting point, but I'm inclined to say that very few languages could come up with {1:this} - Prolog could, I think - and that running into those errors in Python would be user error. That said, this is a good example of the expressivity of this, which mathematical definitions often implicitly disallow.

dalke 13y ago
An analysis shouldn't stop at "user error". Instead, ask if the programming language design plays a role. For example, NUL terminated strings lead to a lot of user errors, some of which lead to security holes. Other string representations don't have that flaw, though come with a different cost concern. Is a buffer overflow "user error"? Some would say it is. But the language design makes those errors more dangerous. Or in Python, there's no technical reason to have a ":" at the end of the line before an indented block. Instead, it's there because user studies show that people learning ABC (which influenced a lot of early Python) made fewer mistakes if the ":" was present than if it wasn't. Are indentation mistakes user error? Certainly users play a role. But again, the design does as well. So saying that something is a "user error" with no further analysis absolves the designer of any responsibility, and I disagree with that idea. There are at least 4 different ways to handle dict+dict in Python. At least three have come up in this thread as the proposed correct solution. Even if there is a mathematically clean solution, if only 10% of the people expect it to work that way, then why should Python introduce something which is so error prone? No support for dict+dict is 100% error prone, of course, but trivially identified in testing. While Counter+Counter-like behavior has subtle consequences that will trip people up. (As another example of the subtleties, consider an inverted index mapping word to a list of document ids: collection_a = {"a": [0, 3, 4], "the": [0, 2, 3]} collection_b = {"a": [5], "an": [6, 7]} collection_c = {"the": [10], "not": [10]} merged_collection = a+b merged_collection += collection_c This is wrong because the += changes merged_collection["the"], which is the same list as collection_a["the"]. So even though it looks like good code, and it is good code for any value where x+=y is the same as x=x+y, it may cause problems which are hard to spot.) "In the face of ambiguity, resist the temptation to guess."

by sesqu 13y ago

dalke 13y ago

An analysis shouldn't stop at "user error". Instead, ask if the programming language design plays a role. For example, NUL terminated strings lead to a lot of user errors, some of which lead to security holes. Other string representations don't have that flaw, though come with a different cost concern. Is a buffer overflow "user error"? Some would say it is. But the language design makes those errors more dangerous. Or in Python, there's no technical reason to have a ":" at the end of the line before an indented block. Instead, it's there because user studies show that people learning ABC (which influenced a lot of early Python) made fewer mistakes if the ":" was present than if it wasn't. Are indentation mistakes user error? Certainly users play a role. But again, the design does as well. So saying that something is a "user error" with no further analysis absolves the designer of any responsibility, and I disagree with that idea. There are at least 4 different ways to handle dict+dict in Python. At least three have come up in this thread as the proposed correct solution. Even if there is a mathematically clean solution, if only 10% of the people expect it to work that way, then why should Python introduce something which is so error prone? No support for dict+dict is 100% error prone, of course, but trivially identified in testing. While Counter+Counter-like behavior has subtle consequences that will trip people up. (As another example of the subtleties, consider an inverted index mapping word to a list of document ids: collection_a = {"a": [0, 3, 4], "the": [0, 2, 3]} collection_b = {"a": [5], "an": [6, 7]} collection_c = {"the": [10], "not": [10]} merged_collection = a+b merged_collection += collection_c This is wrong because the += changes merged_collection["the"], which is the same list as collection_a["the"]. So even though it looks like good code, and it is good code for any value where x+=y is the same as x=x+y, it may cause problems which are hard to spot.) "In the face of ambiguity, resist the temptation to guess."