Re: RFC -- custom operators
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
Re: RFC -- custom operators
On Tue, 7 Aug 2018 at 09:03, Steven D'Aprano wrote: > I'll looking for comments on custom binary operators: would it be useful, > if so, what use-cases do you have? I've never found a need for custom binary operators. I can imagine some *theoretical* cases where they might be useful (but no actual use cases!) but those would almost certainly require relaxing one or more of the restrictions you listed, so they do not even count as theoretical support for your suggested proposal. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC -- custom operators
Steven D'Aprano :
> (1) This proposal requires operators to be legal identifiers,
> such as "XOR" or "spam", not punctuation like % and
> absolutely not Unicode symbols like ∉
Oh, that's a let-down. Operator symbols get their expressive value from
visual conciseness:
life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}
https://en.wikipedia.org/wiki/APL_(programming_language)#G
ame_of_Life>
> (If there aren't any such use-cases, then there's no need for custom
> operators.)
>
> Thoughts?
I have never felt the need for custom operators in Python code. I
believe introducing them will make it harder, not easier, to read code.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
RFC -- custom operators
Request for comments -- proposal to allow custom binary operators. I'll looking for comments on custom binary operators: would it be useful, if so, what use-cases do you have? The most obvious and often-requested use-case would be for a form of logical operator (AND, OR, XOR) that is distinct from the bitwise operators & | ^ but unlike the standard `and` and `or` operators, calls dunder methods. The proposal is to add custom operators. A placeholder syntax might be: spam OP eggs which would then delegate to special dunder methods __OP__ or __ROP__ similar to existing operators such as + and similar. I don't want to get into arguments about syntax, or implementation details, unless there is some interest in the functionality. Please focus on *functional requirements* only. (1) This proposal requires operators to be legal identifiers, such as "XOR" or "spam", not punctuation like % and absolutely not Unicode symbols like ∉ (2) For the sake of the functional requirements, assume that we can parse `spam OP eggs` without any ambiguity; (3) This only proposes binary infix operators, not unary prefix or postfix operators; infix:argument1 OP argument2 prefix: OP argument postfix: argument OP (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? (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? # Left-associative: a OP b OP c# like (a OP b) op c # Right-associative: a OP b OP c# like a OP (b op c) In the last case, that would make chained custom operators intentionally ambiguous (and hence a SyntaxError) unless disambiguated with parentheses: # Non-associative: a OP b OP c# SyntaxError (a OP b) OP c # okay a OP (b OP c) # okay (8) This does not propose to support short-circuiting operators. I'm not interested in hearing theoretical arguments that every infix operator can be written as a function or method call. I know that. I'm interested in hearing about use-cases where the code is improved and made more expressive by using operator syntax and existing operators aren't sufficient. (If there aren't any such use-cases, then there's no need for custom operators.) Thoughts? -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
