Ethan Furman wrote:
The problem with any kind of sigil/keyword is that it becomes line noise -- we would have to train ourselves to ignore them in order to see the structure and variables we are actually interested in. Once we become
Every syntax element can become noise once we're used to it. This is how Groovy is built from Java : they removed everything that can be removed, and still be "understandable" by the compiler. The result is the language being counter intuitive for people that don't do Groovy everyday... Can I write thing like this ? Seems to work... And with that ? Works too, but I don't know if it produces the same effect... We can also think about syntax elements as strucural elements like pillars, helping the thought to elaborate while reading the code. Pillars are constraints for people in a building (they block your view, you have to bypass them, ...), but they helps building bigger constructions, and we're all used to them. In this slightly modified example from the PEP : match entree[-1]: case Sides.SPAM: response = "Have you got anything without Spam?" case "letuce": response = "blablabla" case side: response = f"Well, could I have their Spam instead of the {side} then?" case 1542 | "plop": response = "blablabla2" It's difficult for someone not mastering this feature to see immediatly that "side" will get it's value changed and that the last case will never match. match entree[-1]: case Sides.SPAM: response = "Have you got anything without Spam?" case "letuce": response = "blablabla" case side=: response = f"Well, could I have their Spam instead of the {side} then?" case 1542 | "plop": response = "blablabla2" Here we immediatly see that the first two cases don't work in the same way as the third, because there is "something more". It will even maybe indicate that the last case is useless...
adept at ignoring them, we will again have difficulties when debugging as we won't easily see them. Besides which, the problem is solved:
namespace.var is a lookup var is a store
These rules can't be deduced from a few examples, or from experience from other languages. You have to explicitly learn them. Since newcomers won't propably learn them first (if at all), they won't understand how it works, and they will propably introduce bugs hard to debug. They'll think it's a kind of "swith case" new construct, and will use it that way, completly ignoring the "capturing" property that shows in some cases and not in others. match entree[-1]: case Sides.SPAM: # newcomers will understand that entree[-1] == Sides.SPAM and write the code they need SPAM = "spam" match entree[-1]: case SPAM: # newcomers will understand that entree[-1] == "spam" and write the code they need # ignoring that now, in the following code, SPAM == anything but "spam" # introducing a bug anywhere in the following code where SPAM is expected to hold the # initial value Only a unit test case that test that SPAM has changed can detect this kind of bug. Generally speaking, unit test cases don't test values of "constants" before and after a test case. So it won't even help. Here, we can argue that match is not a "switch case" like syntax, but newcomers from C, Java, Javascript, whatever WILL use it like a "switch case", and WILL read code where it will be used like that. Even if it's not the main use case, it will be used for that, because of 50 years of history of C that we can't ignore. Adding a "=" or something else will at least ring a bell. We can argue that constants should be namespaced, but is it a general way of doing ? People can write "from module import SPAM" or "import module; module.SPAM". This is equivalent, but in one case, it may introduce a bug. Do not forget that Python will be used by many more newcomers, new learners, new developers, data scientists, people with unknow backgrounds, and perhaps few, or no experience in programming. IMHO Python strength is that it's syntax is easy to learn because it is easy to deduce. The some rules that are counter-intuitive like the "else" clause for the loops can't cause any harm if misused because their misuse is detected immediatly, and we can avoid writing them (and most people do). On the other hand, "capturing" variables mixed with "match" variables is counter-intuitive unless you explicitly learn the rules. You can't deduce it (there rules don't exist anywhere else). This feature is central of the PEP and will be used, and will introduce subtle bugs when misused. That's why I consider the rules you stated is not the right way for this feature, and that we should be explicit.