On 3 June 2017 at 17:22, Pavol Lisy <pavol.l...@gmail.com> wrote: > On 6/3/17, Chris Angelico <ros...@gmail.com> wrote: >> On Sat, Jun 3, 2017 at 3:42 PM, Pavol Lisy <pavol.l...@gmail.com> wrote: >>> Sorry for probably stupid question! Is something like -> >>> >>> class A: >>> def __oper__(self, '⊞', other): >>> return something(self.value, other) >>> >>> a = A() >>> a ⊞ 3 >>> >>> thinkable? >> >> No, because operators need to be defined before you get to individual >> objects, and they need precedence and associativity. So it'd have to >> be defined at the compiler level. > > Thanks for clarifying this point. > > Sorry for another stupid question: coding import machinery couldn't be > used too, right? (I mean something like hylang.org ) Because ast could > not understand these operators (and precedence and associativity)?
Source translation frontends *can* define new in-fix operators, but they need to translate them into explicit method and/or function calls before they reach the AST. So a frontend that added "A @ B" support to Python 2.7 (for example), would need to translate it into something like "numpy.dot(A, B)" or "matmul(A, B)" at the Python AST level. It would then be up to that function to emulate Python 3's __matmul__ special method support (or not, if the frontend was happy to only support a particular type, such as NumPy arrays) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
