[Python-ideas] Revisiting dedicated overloadable boolean operators
Steven D'Aprano
steve at pearwood.info
Sat Aug 4 22:28:00 EDT 2018
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
More information about the Python-ideas
mailing list