On Thu, Oct 13, 2011 at 12:43 AM, Raymond Hettinger
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