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

[Yury Selivanov]

Not to mention that support of overloadable boolean operations would be very beneficial for some ORMs too.  As of now we have the only option to write something like: "ops.And(cond1, ops.Or(cond2, cond3))", or to use operators for bit logic with different precedence.

-
Yury

On 2011-10-19, at 3:41 PM, Mike Graham wrote:

> 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
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas