On 07/08/18 08:58, Steven D'Aprano wrote:
Request for comments -- proposal to allow custom binary operators.
[snip]
(1) This proposal requires operators to be legal identifiers,
     such as "XOR" or "spam", not punctuation like % and
     absolutely not Unicode symbols like ∉

Probably wise. I'd personally be inclined to use expressive symbols because I, of course, am an entirely reasonable person whose every choice will be completely intuitive to everyone else (ho ho), but I can imagine other people succumbing to the temptation to trying turning Python in APL.

Also names are probably easier to parse.

(2) For the sake of the functional requirements, assume that
     we can parse `spam OP eggs` without any ambiguity;

Seems like a fair assumption.

(3) This only proposes binary infix operators, not unary
     prefix or postfix operators;

     infix:    argument1 OP argument2
     prefix:   OP argument
     postfix:  argument OP

Other than being easier to parse, is there any particular reason for this choice?

(4) This does not propose to allow the precedence to be
     set on a case-by-case basis. All custom operators will
     have the same precedence.

(5) What should that precedence be?

Low. Names, with their mandatory surrounding spaces, feel more separated and hence lower priority than their operands. I would expect

  x + 1 FROBNICATE q * 4 - 2

to parse as

  (x + 1) FROBNICATE (q*4-2)

(6) This does not propose to set the associativity on a
     case-by-case basis. All custom operators will have
     the same associativity.

(7) Should the operators be left-associative (like multiplication),
     right-associative (like exponentiation), or non-associative?

Either left-associative or non-associative, probably the latter. Most operators that I can think of are left-associative, but you probably want non-associative to avoid subtle bugs with more naturally right-associative operators.

(If there aren't any such use-cases, then there's no need for custom
operators.)

I can't think of any use cases I actually want off-hand. The sorts of things I might apply new operators to are various bits of byte buffer mangling, and most of those feel more pythonic as iterative processes.

--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to