On Mon, Nov 11, 2019 at 4:16 PM David Mertz <me...@gnosis.cx> wrote:

>  I really, really don't get how it's supposed to "transform my thinking
> about coding" to have a slightly different glyph on screen.
>

I agree here. This thread got really caught up in issues like "how do I
type that?", but I don't think that was the OP's point. He was arguing for
"Notations" -- but I, at least have no idea what that means.

He made two specific proposals in the OP:

1) Use a single "left arrow" symbol in place of the two ascii-char := for
the assignment expression operator.

2) phase out the regular old assignment expression altogether eventually.

These are quite independent really.

But that was a lot of work, and a big old thread if the point was simply to
use one non-ascii symbol for one operator -- that clearly won't be
"transformative".

So I *think* the real point to "notations" is really to have  a lot more
operators - each with its own meaning -- *maybe* in place of some
operator overloading. See the other recent thread -- if you want a operator
that means "merge these two dicts", use a new one, rather than trying to
reuse +  -- which has some merit. After all, a number of the objections to
the dict addition proposal was that dict merging is pretty different than
numerical addition, and thus people might get confused.

If you were to introduce a lot more operators, you would get more compact
code, and you probably would want to use a wider range of symbols than
ascii provides, so as to avoid the "ascii soup" to.
referred to.

And I think there is some merit to the "more operators" -- that's exactly
why @ was added -- folks doing matrix calculations really wanted to be able
to write:

A @ B (or A* B) rather than:

np.dot(A, B)

Particularly why we have all the other operators, rather than everything
being a function call. Would we really want:

index(a_list, i)

or

slice(a_sequence, i, j, step)

Making the code look like the math on a blackboard has its advantages.

However, as pointed out in this thread, even in math notation, the same (or
similar) notation has different meaning in different contexts, making it
very hard to take that approach is a general purpose programing language.

So there is a limit -- making everything an operator would be worse than
ascii soup, - it would be hieroglyphics to most of us. like complex math is
to people outside the domain it's used in.

I think we need a mixture of operators and named functions, and that Python
as the balance about right as it is.

The other issue at hand is overloading vs new operators -- and particularly
in a dynamic language, there's something to be said for more operators
rather than overloading -- but i'm really not sure about that -- more than
a handful more, and I think I'd get very confused --even if I could figure
out how to type them.

-CHB
-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PLX37LWNPKC3IC2KUNCV7DSV2OSIM4HA/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to