Chris Angelico writes:

figured out. People will love or hate the proposal based on the tentative syntax, and the "grit on Tim's monitor" check, and such.

Why the lets-use-some-punctuation-for-syntax crowd doesn't just buy Tim a lifetime subscription to monitor-protecting clearsheets so he can remove the grit every day, I just don't know! Win-win AFAICS....

On Mar 20, 2014, at 3:24, Steven D'Aprano wrote:

On Thu, Mar 20, 2014 at 12:41:40AM -0700, Jared Grubb wrote:

The beauty of infix operators is that they give an extremely compact representation, which is valuable for mathematics but not so much for general purpose computing. Consequently, it would be useful to write something like:

matrix @ vector

versus

matrix.mult(vector)

because the symbol for the operator is so compact. Having to write it as this instead:

matrix`mult`vector

saves you one character over the method syntax,

It's not about saving one character, it's about saving the (possibly overly-nested) parentheses. The PEP explains that, as does the earlier thread, and all of the previous threads and PEPs on related ideas, so I won't go into it again. However, the other answers are right; matrix multiplication _is_ special. As an alternative to the 2000 PEP that proposed a suite of new operators by allowing ~ as a prefix to 11 existing operators )or to the other proposal to allow any string of operator characters to be defined as an operator), I think general infix wins. However, the NumPy community is no longer suggesting either of those; after 14 years of living with the limitations of the current system, they've decided that only one operator is really a problem. And against that proposal, general infix loses. One is a good number of special cases for the same reason 11 is a bad number of special cases. Of course I still like my general infix proposal, but even if we had it, I think @ for matmul might be worth adding anyway.

On Thu, Mar 20, 2014 at 4:14 PM, Ron Adam wrote:

def foo(...): symbol b

s = 'a' b 'c'

Actually makes me think of decorators, which means that you wouldn't even need new tokens or keywords: from functools import make_operator bop = make_operator(b) s = 'a' bop 'b' class Ops: @make_operator def cat(left, right): return left + right t = 'a' Ops.cat 'b' It reduces the grit, but also reduces certain kinds of obviousness. bwm

On Mar 20, 2014 8:16 PM, "Steven D'Aprano" wrote:

On Thu, Mar 20, 2014 at 05:04:25PM -0400, Brandon W Maister wrote:

...

Actually makes me think of decorators, which means that you wouldn't

even

...

need new tokens or keywords:

But you would require new syntax. Your suggested syntax

s = 'a' bop 'b'

is currently a syntax error.

100% agree, I was careful with my language, if not my thinking :-)

Keep in mind that any changes to syntax would allow bop to be any arbitrary object. Python cannot tell at compile-time whether bop is an "operator" or a list or a string or a float, only at run-time.

I admit that when writing I didn't think about the fact that I was suggesting adding dynamic names to what is currently a static table.

...

from functools import make_operator bop = make_operator(b)

Do you have any suggestion as to how make_operator would work? What should it do?

Originally I was thinking something along the lines of "just add it to the 'operators' dict" but obviously that won't work since there's no such thing. Before I defend the idea any further I need to point out that I don't think it's a *good* idea. I kind of like the idea of arbitrary infix functions, so I threw out an idea that I haven't seen before. We could, hypothetically, create an "operators" dict (or dicts) alongside locals and globals. Then, if an unexpected token shows up in operator position (which is probably well-defined?) before a SyntaxError is raised the token is looked up in the operators dict. I think that the biggest problem I have with that solution is that philosophically it seems like it would take Python a bit far into the lisp-2 camp, which I would not like.

What sort of object is bop? A regular function that takes one or two args. Honestly the nice thing about the "look it up somewhere if it causes the right kind of SyntaxError" solution is that it would probably also allow arbitrary unary operators. Although why anyone would want *that* is beyond me, so maybe it's not nice :-)

bwm

On Mar 20, 2014, at 19:49, Chris Angelico wrote:

On Fri, Mar 21, 2014 at 12:28 PM, Brandon W Maister wrote:

...

We could, hypothetically, create an "operators" dict (or dicts) alongside locals and globals. Then, if an unexpected token shows up in operator position (which is probably well-defined?) before a SyntaxError is raised the token is looked up in the operators dict.

The SyntaxError is raised at compilation time; locals and globals are at run time. The only way that would work is if you do something like this:

operators["b"] = lambda left, right: whatever import module_using_b

Or, alternatively, instead of a SyntaxError this would compile into a call to b, which would then give a NameError at runtime. And I suppose you could argue that's just taking dynamic typing one step further. But I seriously doubt anyone actually wants typos like "esle" to compile successfully... Also, imagine what it would look like to chain these: spam spam eggs baked beans spam spam Maybe the parser can figure out that the spam, baked, and spam are operators and the spam, eggs, beans, and spam are operands, but what hope does any human have? Obviously that example is over the top, but try it with a tree constructor or the other examples from this thread and it's still painful. The Haskell-style backticks solve all of these problems: the coder can't accidentally write an infix operator when he meant something else, the parser can distinguish infix operators from typos at compile time, and the reader can tell (unless he's stolen Tim's monitor grit) which things are operators and which are operands. (Of course you could deliberately confuse people with weird spacing, but Python doesn't have to make it impossible to write intentionally obfuscated code, it just has to avoid making it easy to write accidentally obfuscated code.)

On Fri, Mar 21, 2014 at 4:01 PM, Ethan Furman wrote:

On 03/20/2014 08:40 PM, Andrew Barnert wrote:

...

Also, imagine what it would look like to chain these:

spam spam eggs baked beans spam spam

Maybe the parser can figure out that the spam, baked, and spam are operators and the spam, eggs, beans, and spam are operands, but what hope does any human have?

Why would spam be able to be both a variable and an operator? Hmm, perhaps because of the first-class citizen thing -- so the leading grit says "make it work" and without it is just passing it around.

If the creation of an operator is done by putting something into the current namespace, then it has to be available as some sort of object. On the other hand, if it's something done as a declaration, or a pre-import keyword mapping, then it should be a keyword (like other word operators, "if" and "else" and such), and unavailable for assignment. In theory, this could be done as: from __aether__ import spam as operator where "as operator", instead of specifying the name to bind to, specifies that it be something other than a name. (Preferably, it should use a keyword, rather than "operator", which is a valid name.) This would go immediately under future statements, and would affect the compilation of that module: any instance of the word "spam" is now a keyword operator, so the above would be invalid. I'm still not convinced it would be a good thing, but this at least gives a per-module way to create operators. ChrisA

From: Python-ideas [mailto:python-ideas-bounces+andy.henshaw=gtri.gatech.edu@python.org] On Behalf Of Ethan Furman

On 03/20/2014 08:40 PM, Andrew Barnert wrote:

...

Also, imagine what it would look like to chain these:

spam spam eggs baked beans spam spam

Maybe the parser can figure out that the spam, baked, and spam are operators and the spam, eggs, beans, and spam are operands, but what hope does any human have?

Why would spam be able to be both a variable and an operator? Hmm, perhaps because of the first-class citizen thing -- so the leading grit says "make it work" and without it is just passing it around.

Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo

On 03/21/2014 07:19 AM, Henshaw, Andy wrote:

From: Python-ideas [mailto:python-ideas-bounces+andy.henshaw=gtri.gatech.edu@python.org] On Behalf Of Ethan Furman

...

On 03/20/2014 08:40 PM, Andrew Barnert wrote:

...

Also, imagine what it would look like to chain these:

spam spam eggs baked beans spam spam

Maybe the parser can figure out that the spam, baked, and spam are operators and the spam, eggs, beans, and spam are operands, but what hope does any human have?

Why would spam be able to be both a variable and an operator? Hmm, perhaps because of the first-class citizen thing -- so the leading grit says "make it work" and without it is just passing it around.

Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo

Python, however, is not English, and would only recognize two different objects from the above, so that would be a SyntaxError. -- ~Ethan~

On Fri, Mar 21, 2014 at 3:06 PM, Mark Daoust wrote:

...

...

...

spam `spam` eggs `baked` beans `spam` spam

I'm not sure if the backticks help.

Backticks never help. They hide amongst the beefier characters. That's one reason why $(...) is preferred by most Bash users and repr() by most Python users. Let them die the quiet death they deserve. Skip