py/grammar.h: Add matmul operator (@) as per PEP 465. - #4740

+20 bytes according to the Travis results.

Appveyor failed due to CPython 3.4 on the Windows build. Will make the test conditional.

Appveyor failed due to CPython 3.4 on the Windows build. Will make the test conditional.

For such tests a .py.exp file is usually provided (see eg tests/basics/python36.py)

Thanks :) Done

This is the code size change I measure locally:

   bare-arm:   +16 +0.024% 
minimal x86:   +80 +0.052% 
   unix x64:  +176 +0.036%
unix nanbox:  +144 +0.033% 
      stm32:   +32 +0.009% 
     cc3200:   +24 +0.013% 
    esp8266:   +80 +0.012% 
      esp32:   +36 +0.003%

So it might be worth thinking of ways to minimise this impact. It could be made compile-time configurable but that's going to be rather messy.

Also a breaking change to the bytecode as the op table changes (but my understanding is that this is OK between micropython versions?)

Bytecode version already changed since the last release, so there is scope to make a change again before the next release.

So it might be worth thinking of ways to minimise this impact. It could be made compile-time configurable but that's going to be rather messy.

+1, this is a pet operator of numpy, which I never saw to be used anywhere else. (Then maybe numpy support for MicroPython would be important, but I didn't see someone arguing that. And then support for @ would be again among the last things to care about, after 95% of other functionality.)

numpy support for MicroPython would be important, but I didn't see someone arguing that.

Well, it would be pretty awesome. We actually have more than one usecase here where we have uPy code dump data to a binary format, then launch a CPython process to deal with it in numpy and get results from that back into uPy. However that's just us, and numpy is like the opposite of 'micro', so I can see why it's not there yet.

@dpgeorge Good thinking on the switch statements. Especially the non-inplace one benefitted because it could take advantage of the table already used in parse.c.

   bare-arm:    -4 -0.006% 
minimal x86:   +48 +0.031% 
   unix x64:  +128 +0.026% [incl +32(data)]

@pfalcon Yes it's highly specialised for numpy, it's literally called "matmul" for a reason. Actually it's pretty high on the list of things to care about because it's a good feature that people use, it means that existing code will work without modification, and it avoids an error-prone conversion of a @ b to numpy.matmul(a, b).

See #4947 for a reworked version of this.

Superseded by #4947