[Python-ideas] Break the dominance of boolean values in boolean context

[Nick Coghlan]

On Fri, Sep 16, 2011 at 6:18 AM, Eric V. Smith <eric at trueblade.com> wrote:
> On 9/15/2011 2:00 AM, Nick Coghlan wrote:
>> On Thu, Sep 15, 2011 at 3:30 PM, Chris Rebert <pyideas at rebertia.com> wrote:
>>> On Wed, Sep 14, 2011 at 9:22 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>>> <snip>
>>>> NumPy is not the only use case by a long shot. The main reason
>>>> I want it is for expressing database queries. You only have to
>>>> look at the contortions that things like Django have to go
>>>> through to wonder whether there's a better way.
>>>
>>> So, you want this in order to avoid (e.g.) `X & Y` and `not_(Z)`, in
>>> favor of `X and Y` and `not Z`? Doesn't seem like that big of a win in
>>> the `and` and `or` cases.
>>
>> It's actually:
>>
>> 'x and y' vs 'x & y'
>> 'x or y' vs 'x ^ y'
>> 'not x' vs '~x'
>
> The problem with this is the precedence difference between '&' and
> 'and', etc.
>
> sqlalchemy uses this approach, and my code contains many extra sets of
> unnatural looking parens to deal with this issue. It's not a huge deal,
> but I see newbies (and me, and oldie) leaving off the parens. It's not
> an easy bug to track down.

Yeah, Greg does mention that in the PEP. Some concrete examples showing:
- buggy code with bitwise operator overloading
- correct code with parens used to correct bitwise precedence disparity
- correct code with boolean logic overloading (as proposed by the PEP)

would help make it crystal clear.

Those would also help decide how important it is to preserve the
short-circuiting semantics when overloading the operations -
element-wise and DSL type use cases are always going to need the RHS,
so there may be an opportunity there to simplify the proposed
semantics to match those of other binary operations.

And, of course, the final option is to go the C/C++ route: leave
and/or/not as short-circuiting flow control statements and introduce
&& and || as low precedence binary logical operators. (I can't see
Guido ever going for that idea, but it *does* sidestep the concerns
about currently legal control flow transformations)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia