[Python-ideas] Revisiting dedicated overloadable boolean operators

[Steven D'Aprano]

On Sat, Aug 04, 2018 at 02:04:01PM +0000, Dan Sommers wrote:
> On Sat, 04 Aug 2018 23:13:34 +1000, Steven D'Aprano wrote:
> 
> > There are certainly advantages to using binary operators over named
> > functions, and a shortage of good, ASCII punctuation suitable for new
> > operators.
> 
> Hold that thoght.
> 
> Then again, why is it 2018 (or 5778?) and we're still stuck with ASCII?
> Doesn't Unicode define a metric boatload of mathematical symbols?  If
> Pythong allows Unicode names,¹ why not Unicode operators?

Some social problems:

- allowing non-ASCII identifiers was controversial, and is still
  banned for the std lib;

- according to critics of PEP 505, even ASCII operators like ?.
  are virtually unreadable or unspeakably ugly and "Perlish".


If you think the uproar over PEP 572 was vicious, imagine what would 
happen if we introduced new operators like ∉ ∥ ∢ ∽ ⊎ etc instead. I'm 
not touching that hornet's nest with a twenty foot pole.


And some technical problems:

- keyboard support for entering the bulk of Unicode characters is
  non-existent or poor;

- without keyboard support, editor support for entering Unicode
  characters is as best clunky, requiring the memorization of
  obscure names, hex codes, or a GUI palette;

- and font support for the more exotic code points, including most
  mathematical operators, is generally rubbish.

It may be that these technical problems will *never* be solved. But let 
other languages, like Julia, blaze this trail.


[...]
> > I think that before adding more ad hoc binary operators, we ought to
> > consider the possibility of custom operators [...]
> > 
> >     a ~foo b
> 
> Great.  Yet another way to spell a.foo(b).  Or foo(a, b).  :-/

Indeed.

Technically, we don't need *any* operators at all, possibly aside from 
those that do argument short-circuiting.

But for many purposes, we much prefer infix notation to prefix 
function notation. Which would you rather read and write?

    or(x, 1)

    x or 1


[...]
> And now mental gymnastics to jump from ~foo to ___foo___ or ___rfoo___.

Just as we do "mental gymnastics" to jump from existing operators like + 
to __add__ or __radd__.

If you don't like operator overloading *at all*, that ship has 
already sailed.


> If it's too hard to tell = from == 
> (see endless threads on this mailing list for proof)
> then it's also too hard to tell __xor__ from ___xor___.

*shrug*

I don't think it is, but I'm open to alternative suggestions.


> If I want to say
> 
>     a ~foo b
> 
> then why can't I also say
> 
>     class A:
>         def ~foo(self, b):
>             pass # do something more useful here

Infix operators delegate to a pair of methods. What would you call 
the second one? ~rfoo  will clash with operator rfoo.

We already have a convention that operators delegate to dunder methods, 
and I see no reason to make changes to that convention. It's a *good* 
convention.

The smaller the number of changes needed for a proposal, the better its 
chances of being accepted. My suggestion requires:

- one new piece of syntax, ~op or equivalent, as a binary operator;

- (possibly) one slight extension to an existing naming convention;

- (possibly) one new byte-code;

- no new keywords, no new syntax for methods, no new built-in types, 
  no changes to the execution model of the language, and no changes
  to the characters allowed in Python code.


If you want to make a counter-proposal that is more extensive, be my 
guest :-)



-- 
Steve