Other notes

[Mike Meyer]

[...]

Well, perhaps you can explain how a change that's made at run time
(calling the decorator) can affect the parser's compile time behavior,
then. At the moment, IIRC, the only way Python code can affect the
parser's behavior is in the __future__ module, which must be imported
at the very head of a module.

By modifying the parsers grammer at runtime. After all, it's just a
data structure that's internal to the compiler.

But the parser executes before the compiled program runs, was my
point. What strange mixture of compilation and interpretation are you
going to use so the parser actually understands that ".." (say) is an
operator before the operator definition has been executed?

Ok, current decorators won't do. Clearly, any support for adding infix
operators is going to require compiler support.

<mike

 

[Mike Meyer]

Given that xx.py is parsed in its entirety *before* runtime, that answer is
no answer at all. Runtime parser changes (far, far from trivial) could
only affect the result of exec and eval.

and import. I.e., you could do:

import french
import python_with_french_keywords

<mike

 

[beliavsky]

OTOH, there is precedent in e.g. fortran (IIRC) for named operators of the
form .XX. -- e.g., .GE. for >= so maybe there could be room for both.

Yes, but in Fortran 90 "==", ">=" etc. are equivalent to ".EQ." and
".GE.". It is also possible to define operators on native and
user-defined types, so that

Y = A .tx. B

can be written instead of the expression with the F90 intrinsic
functions

Y = matmul(transpose(A),B)

The Fortran 95 package Matran at
http://www.cs.umd.edu/~stewart/matran/Matran.html uses this approach to
simplify the interface of the Lapack library and provide syntax similar
to that of Matlab and Octave.

I don't know if the syntax of your idea clashes with Python, but it is
viable in general.