[Python-ideas] Infix functions

[Andrew Barnert]

On Feb 22, 2014, at 19:17, Bruce Leban <bruce at leapyear.org> wrote:

> On Sat, Feb 22, 2014 at 5:23 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>> For example, I'd like to use
>> ∪ and ∩ for set union and intersection, but instead those two operations
>> get mapped to & and | and I can never remember which is which. I'd like
>> to use operators such as ⊕ ⊗. But so long as Python operators are ASCII
>> only, that cannot happen.
> 
> What if Python didn't restrict you to ASCII operators?

That was something the PEP 225 (might have got it wrong from memory; I'm on my phone) envisioned as a future solution, in the far off day that Python and source editors could handle Unicode. And we have pretty much reached that day. So I'm not sure why I didn't pick up on this; thanks for bringing it up!

However, there is still a big problem typing these symbols. Unicode hasn't meant a resurgence in APL, after all... A handful of them are available as opt-sequences on Mac, but most aren't. And on other platforms, where you have to use alt+keypad, none of them are typeable. Of course powerful enough editors can easily take care of this problem, but is it acceptable to say "if you want to use fancy operators, you have to use emacs, vi, or some not-yet-released version of Eclipse or PyCharm"? (Maybe it is; this is a real question, not rhetorical...) And it's not just editing code; if I want to import a module at the interactive prompt in my terminal or IDLE and call one of these functions, if I want to write a code snippet in an email or a StackOverflow answer, etc., I need an input method that works there (or I need to copy and paste from emacs).

Finally, this is even _more_ specific to mathematical use cases. If I want to inline a higher-order function, there will likely be no obvious mathematical symbol for most of them.

> Here's specifics of how that could work:
> 
> (1) An extended operator is a single math symbol character, e.g., ∩ or ⊕ or ⊲ but not ⊲⊲. The set of allowed characters needs to be defined carefully. It could be any Unicode S-class character with the math property. Extended operators can be combined with an equal sign to do in-place updating, e.g., A ∩= B.

That seems like a good first cut at the rule.

> (2) Extended operators can be declared like this.
> 
> class sample:
>     def '∩'(self, rhs):
>         return self.value.intersection(sample.get_set(rhs))

That's the same syntax the PEP envisioned. They also wanted to change __add__ to '+', which probably seemed more reasonable in the early 2.x days than after 20 years of history.

> And I probably need to write sample['∩'] not sample.∩.

This part I don't like. In Python, attribute access and keyed access are different; namespaces are not dictionaries and vice-versa.

And it argues against the quoted operator syntax (unless you want to allow quotes for attribute access...).

But I'm not sure what the right answer is.

> (3) All extended operators have the same precedence, between comparisons and bitwise or.

I definitely agree with a fixed precedence (and associativity) that they all share. 

That specific choice is the same precedence I suggested for `operators`. But I did that based on writing a bunch of expressions mixing operators and seeing what looked most "natural". I'd have to look at the same examples with Unicode operators to see if it still looks right.

> Perhaps expressions mixing different extended operators always require parentheses, i.e., (A ∪ B ∩ C) would be a syntax error.

With backtick operators this doesn't seem necessary, but for Unicode symbols, I think you're right. The natural way to read that is for intersection to bind more tightly, which is not what the rule would do. So a SyntaxError is better than misleading code.

> To my mind this is way more readable than something like *%+& which looks like someone cursing. :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140222/626e46c5/attachment-0001.html>