[Python-ideas] PEP 355 (overloading boolean operations) and chained comparisons

[Mike Graham]

On Thu, Oct 13, 2011 at 12:43 AM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
>
> Have you considered that what-is-good-for-numpy isn't necessarily good for Python as a whole?
> Extended slicing and ellipsis tricks weren't so bad because they were easily ignored by general users.  In contrast, rich comparisons have burdened everyone (we've paid a price in many ways).

Rich comparisons added complication to Python, but was a very
worthwhile feature. In addition to numpy, they are used by packages
like sqlalchemy and sympy to give a more natural syntax to some
operations. The introduction of rich comparisons also included the
introduction of Notimplemented (IIRC), which adds even more
complication but makes it possible to write more powerful code.

__cmp__ also had a somewhat odd (though not unique) API, which I many
times saw confuse learners.

In any event, I don't think rich comparisons affect most users, who
very seldom have an excuse to write a set of comparison operators
(using __cmp__ or rich comparisons).

> The numeric world really needs more operators than Python provides (a matrix multiplication operator for example), but I don't think Python is better-off by letting those needs leak back into the core language one-at-a-time.

Having used numpy fairly extensively, I disagree. I don't mind having
to call a normal function/method like solve, dot, conj, or transpose
in circumstances where a language like Matlab would have a dedicated
operator. In fact, I could argue for these things that what Python
does Python's way is superior to Matlab's in particular, as most of
these operators have or are related to problematic features or syntax.
I do, however, regularly write "(a < b) & (b < c)" and hate it; a
little observation reveals is it quite terrible.

That being said, I think the fault might be as much numpy's as
anything. An API like b.isbetween(a, c) or even (a < b).logicaland(b <
c) would probably be nicer than the current typical solution. Though
these fall short of being able to write a < b < c, which would be
consistent and obvious, they would perhaps be enough to weaken the
idea that a semantic change in Python could be beneficial.


I'm still not seeing the great harm this will have on normal Python
programmers who don't wish to overload boolean operators. Unlike rich
comparisons, which deprecated the standard way to do thins, in this
case the developer using Python can do the exact same thing she was
doing all along and get the same results.

Mike