[Python-ideas] Revisiting dedicated overloadable boolean operators

[Steven D'Aprano]

On Sat, Aug 04, 2018 at 09:16:35PM -0400, Todd wrote:

[Chris said:]
> > You say that Python doesn't have them. What aspect of boolean
> > operators doesn't Python have?
> >
> 
> Python's "and" and "or" don't return "True" or "False" per se, they return
> one of the inputs based on their respective truthiness.  So although they
> are logical operators, they are not strictly boolean operators.

According to Python's rules for truthiness, they are boolean operators. 
According to Python's rules, True and False aren't the only boolean 
values. They're merely the canonical true and false values, but 
otherwised unprivileged.

So I don't think this is a difference that makes any real difference. 
You might as well complain that Python doesn't strictly have ints, 
because some other languages limit their ints to 32 or 64 bits, and 
Python doesn't.

But either way, this isn't a really important factor. If we add 
overridable "boolean operators" like bOR and bAND, the fact that they 
can be overridden means that they won't be limited to returning True and 
False either:

- numpy elementwise operators will return arrays;

- sympy will return symbolic expressions;

- ternary logic will return trits (say, true/false/maybe);

etc. So the question of Python truthiness is not really relevant.


[...]
> In your example, you are intentionally picking a character purely because
> it happens to look similar to a completely different character.  That isn't
> the sort of thing that can happen innocently or by accident.

I see lots of newbies, and experienced coders who ought to know better, 
using variables like l and sometimes even O. Don't underestimate the 
power of laziness and thoughtlessness.

On the other hand, such poor choices are easily fixed with a gentle or 
not-so-gentle application of the Clue Bat and a bit of minor 
refactoring. Changing variable names is easy. Likewise, if somebody 
chooses an ugly custom operator like O01l it isn't hard to refactor it 
to something more meaningful.


> By contrast,
> using a valid mathematical symbol for the corresponding mathematical
> operation is exactly the sort of thing allowing new operators is meant to
> support.

The term "strawman fallacy" gets misused a lot on the internet, mostly 
by people who use it as a short-hand for:

    Dammit, you've just found the flaw in my argument I didn't
    notice, so I'll try to distract attention by falsely accusing
    you of a fallacy.

But your comments about symbols like ＋ truly are a strawman:

    Substituting a person’s actual position or argument with a 
    distorted, exaggerated, or misrepresented version of the
    position of the argument.

https://www.logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/169/Strawman-Fallacy

I never proposed supporting arbitrary Unicode symbols like ＋ (full 
width plus sign), in fact the opposite, I explicitly ruled it out. In 
response to a question about supporting Unicode operators, I said

"I'm not touching that hornet's nest with a twenty foot pole."

and listed a number of social and technical reasons for not supporting 
Unicode operators. I said that the operators would have to be legal 
identifiers.

So no, operators like ∉ ∥ ∢ ∽ ⊎ and ＋ are not an option under my 
proposal.



-- 
Steve