[Python-Dev] Infix operators

[Charles Hixson]

On Saturday 26 July 2008 01:23:17 am Nick Coghlan wrote:
> Sebastien Loisel wrote:
> > However, just for posterity (and I'm not going to pursue the argument
> > further than this), I'll say this. The problem of determining the
> > meaning (or overridability or whatever) of x=4$6 is the same as the
> > problem of determining the meaning of x=fooz(4,6). Since it's not a good
> > argument against user-defined functions, I don't see it as a good
> > argument against user-defined operators.
>
> The namespace of usefully mnemonic function names is infinitely larger
> than that of usefully mnemonic punctuation marks. User-defined functions
> are good, but once you have those there is no reason to have
> user-defined operators *as well*.
>
> Cheers,
> Nick.
>
Most mathematicians would disagree with you.  I'll grant that it tends to make 
the code extremely obscure to those who don't work in the field, but it tends 
to make it much clearer to those who do so work.

OTOH, it's also true that there aren't sufficient punctuation symbols.  E.g. 
math people drafted capital sigma as sum of a series, etc.

Therefore it seems to me that the appropriate thing is to create a convention 
that bar-somethingprintable-bar should be interpreted as a user defined 
operation, e.g. |+| or |@#|.  The first one is reasonable as matrix 
multiplication, the second as some user defined operation that hasn't yet 
been specified (in this context).  And since such things don't yet have 
a "secret name" I would suggest that they be defined either via an ordinary 
def, or via a def with their name in quotes, i.e., either:
def |+|   or   def "|+|"

If an ordinary functional reference is desireable (probably) there could be a  
decorators that assigned the name, and possibly the precedence, e.g.:
@name=madd
@precedence="+"
def |+| (a, b):
   etc.

The main drawback that I see is that code that relies heavily on this approach 
would become much less readable to anyone not in the particular field.  Think 
of the first time you encountered the curl or del operators, or even the 
kronecker delta.

OTOH, it seems far too late in the development process to be inserting such a 
change in Python 2.6 or 3.0.  If this is important to you, you should 
probably propose it for 2.7/3.1.