On 11/15/2020 11:18 PM, Stephen J. Turnbull wrote:
Jim J. Jewett writes:
> What advantage can there be in re-using syntax to mean something
> opposite to what it normally does?
In math, it allows us to write "solve c = f(x) for x". That doesn't
mean "bind c to the value f(x)", it means exactly the opposite. No
problem here, I suppose. So
match p:
case Point(x=a, y=b):
is a way of saying "solve p = Point(x=a, y=b) for a and b".
I understand your distaste for this syntax, but I see no problem
in principle. It's a problem of programmer habits and the evident
inconsistency with forms like "case Point(x=1, y=2)". This is
especially true when a or b is already bound.
Indeed. Mathematics never came up with separate symbols for equality and
assignment. Neither did early programming languages. That was a source
of confusion for many programmers.
Then someone invented == for equality comparison, and = for assignment,
or alternately := for assignment and = for equality comparison. Python
now has the first three, many other languages only have one of the pairs.
This reduced the confusion and resulting bugs, although some still
happen. Linters help avoid them, and even some compilers emit warnings
for possibly misused operators of those pairs.
In mathematics, equality might be written a = b or b = a, transitively
irrelevant.
But I have never seen assignment in mathematics be anything but var =
value, as in
"let x = 3" or "let x = <some constant or expression>". Maybe I'm just
uninformed regarding current practice, but I do have a degree in
mathematics, albeit somewhat dated at this point.
So I also have a distaste for any syntax that puts an assignment target
on the right, it seems like a step toward reintroducing confusion and
bugs. The pattern match operator seems complex enough without
(re-)introducing confusion regarding assignment operators.
In your example "solve c = f(x) for x", that is not an assignment
operator, but an equality comparison operator in an equation. Although I
know a few exist, I'm not familiar with programs that do symbolic
algebra, to know how they notate such instructions: most programming
language do not do symbolic manipulations. But note that your example
is wordier than "let c = f(x)" which would be an assignment operation.
And note that it _needs to be wordier_ to convey the proper mathematical
semantics. At least, it did back when I was in math classes.
Just because something is syntactically unambiguous, doesn't mean it
makes a good user interface.
_______________________________________________
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/A7OGGP3YKYD32LYCYC3NWNUWC7ICUPIX/
Code of Conduct: http://python.org/psf/codeofconduct/
