On Mon, Nov 11, 2019 at 4:16 PM David Mertz
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