[Python-ideas] [Python-ideos] Dedicated overloadable boolean operators

[Nathaniel Smith]

On Nov 24, 2015 11:53 AM, "Guido van Rossum" <guido at python.org> wrote:
>
> On Tue, Nov 24, 2015 at 11:37 AM, Nathaniel Smith <njs at pobox.com> wrote:
> > On Nov 24, 2015 10:21 AM, "Guido van Rossum" <guido at python.org> wrote:
> >>
> >> To everyone claiming that you can't overload and/or because they are
> >> shortcut operators, please re-read PEP 335. It provides a clean
> >> solution -- it was rejected because it adds an extra byte code to all
> >> code using those operators (the majority of which don't need it).
> >
> > The semantic objection that I raised -- short circuiting means that you
> > can't correctly overload 'True and numpy_array', because unlike all other
> > binops the overload must be defined on the left hand argument -- does apply
> > to PEP 335 AFAICT. This problem is IMHO serious enough that even if PEP 335
> > were accepted today I'm not entirely sure that numpy would actually
> > implement the overloads due to the headaches it would cause for teaching and
> > code review -- we'd have to have some debate about it at least.
>
> OK, that's useful feedback. Is NumPy interested in coming up with an
> alternative that works, or are you fine with the status quo?

We'd certainly love it if there were a better alternative, but --
speaking just for myself here -- I've hesitated to wade in because I
don't have any brilliant ideas to contribute :-). The right-hand-side
overload problem seems like an inevitable consequence of
short-circuiting, and we certainly aren't going to switch 'and'/'or'
to become eagerly evaluating. OTOH none of the alternative proposals
mooted so far have struck me as very compelling or pythonic, if only
because all the proposed spellings are ugly, but, who knows, sometimes
something awesome appears deep in these threads.

Two thoughts on places where it might be easier to make some progress...

- the 'not' overloading proposed in PEP 335 doesn't seem to create any
horrible problems - it'd be a minor thing, but maybe it's worth
pulling out as a standalone change?

- the worst code expansion created by lack of overloading isn't
  a == 1 and b == 2
becoming
  (a == 1) & (b == 2)
but rather
  0 < complex expression < 1
becoming
  tmp = complex expression
  (0 < tmp) & (tmp < 1)
That is, the implicit 'and' inside chained comparisons is the biggest
pain point. And this issue is orthogonal to the proposals that involve
adding new operators, b/c they only help with explicit 'and'/'or', not
implicit 'and'. Which is why I was sounding you out about making
chained comparisons eagerly evaluated at the bar at pycon this year
;-). I have the suspicion that the short-circuiting semantics of
chained comparisons are more surprising and confusing than they are
useful and we should just make them eagerly evaluated, and I know you
have the opposite intuition, so I think the next step here would be to
collect some data (run a survey, scan some code, ...?) to figure out
which of us is right :-).

The latter idea in particular has been on my todo list for at least 6
months and still has not bubbled up near the top, so if anyone is
interested in pushing it forward then please feel free :-).

-n