On 18/07/2020 11:23, emmanuel.coir...@caissedesdepots.fr wrote:
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.
+1
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.
+1
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.
+1. Explicit is better than implicit.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/HQLSHN4IJSN36I4R6D6DUVDTJTYEZW4O/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/W7BZRTNY6TI5WHC5YRBOZOMDVSNEOGC2/
Code of Conduct: http://python.org/psf/codeofconduct/
