[Python-Dev] Infix operators (original) (raw)

Charles Hixson charleshixsn at earthlink.net
Sun Jul 27 19:43:38 CEST 2008

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.

More information about the Python-Dev mailing list