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

[Nick Coghlan]

On 24 November 2015 at 11:38, Chris Barker - NOAA Federal
<chris.barker at noaa.gov> wrote:
> I think first we decide it is or isn't a good idea, and then decide
> how to spell it, but .and. and .or. kind of appeal to me.

I think it's reasonably clear that rich logical operators with
appropriate precedence and non-shortcircuiting behaviour would be a
nice feature to have, the question is whether or not they can be
introduced without making things even more confusing than they already
are. Using placeholder syntax, let's consider the three operations:

  A rich_and B
  A rich_or B
  rich_not A

To explain this fully will require explaining how they differ from:

  A and B  -> A if not bool(A) else B
  A or B  -> A if bool(A) else B
  not A -> not bool(A)

and:

  A & B -> operator.and_(A, B)
  A | B -> operator.or_(A, B)
  ~A -> operator.not_(A)

Depending on a user's background, it will also potentially require
explaining how they differ from these operations in C and other
languages:

  A && B
  A || B
  !A

Casting any new forms specifically as "matrix" operators (like the new
matmul operator Jelte referenced in the opening message of the thread)
also runs into problems, since "@" is a genuinely distinct operation
only applicable to matrices, while the goal here is instead to
broadcast an existing operation over the array elements, which matrix
objects are already able to do implicitly for most binary operators.

Something that *could* potentially be comprehensible is the idea of
allowing "elementwise" logical operators, with a suitable syntactic
spelling. There'd still be a slight niggle to explain why and/or/not
have explicitly elementwise variants when other binary operations
don't, but that would likely still be less confusing than explaining
the use of the bitwise operators.

Regards,
Nick.

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