On 16 May 2015 at 07:35, Nathaniel Smith firstname.lastname@example.org wrote:
On Thu, May 14, 2015 at 11:53 PM, Nathaniel Smith email@example.com wrote:
On Thu, May 14, 2015 at 9:29 PM, Guido van Rossum firstname.lastname@example.org wrote:
I expect you can make something that behaves like list by defining __mul__ and __rmul__ and returning NotImplemented.
Hmm, it's fairly tricky, and part of the trick is that you can never return NotImplemented (because you have to pretty much take over and entirely replace the normal dispatch rules inside __mul__ and __rmul__), but see attached for something I think should work.
So I guess this is just how Python's list, tuple, etc. work, and PyPy and friends need to match...
For the record, it looks like PyPy does already have a hack to implement this -- they do it by having a hidden flag on the built-in sequence types which the implementations of '*' and '+' check for, and if it's found it triggers a different rule for dispatching to the __op__ methods: https://bitbucket.org/pypy/pypy/src/a1a494787f4112e42f50c6583e0fea18db3fb4fa...
Oh, that's rather annoying that the PyPy team implemented bug-for-bug compatibility there, and didn't follow up on the operand precedence bug report to say that they had done so. We also hadn't previously been made aware that NumPy is relying on this operand precedence bug to implement publicly documented API behaviour, so fixing it *would* break end user code :(
I guess that means someone in the numeric community will need to write a PEP to make this "try the other operand first" "feature" part of the language specification, so that other interpreters can implement it up front, rather than all having to come up with their own independent custom hacks just to make NumPy work.
P.S. It would also be nice if someone could take on the PEP for a Python level buffer API for 3.6: http://bugs.python.org/issue13797