On 2018-07-19 02:11, Chris Angelico wrote:
Okay. What about bitwise operators, then? They don't have centuries of
mathematical backing to support them, yet it isn't considered
"unpythonic" to have &|^~ peppering our code. Judging by the current
levels of backlash against symbolic operators, it would have been
better to use "more explicit" function calls for all bitwise
operations. Coalescing None to a value is_at least_ as common as
performing bit manipulations in integers.
The use of & to mean "and" does indeed have centuries of backing to
support it. The other operators, and the use of & to specifically mean
bitwise-and, are newer, but still go back decades in other programming
languages. Moreover, the fact that these are bitwise versions of more
general logical operations (conjunction, disjunction, etc.) means that
they can be overridden for custom types in a way that is still
intuitive. For instance, sets override & to mean "intersection" because
it means "everything that is in set A AND in set B", and similarly for |
and ^.
So basically I do not regard these operators as bitwise operators.
They are symbols standing for logical operations. Their default
implementations on built-in numeric types do bitwise operations, but
that is not what the symbols "mean". Their meaning is more general and
bitwise operations are one reasonable narrowing of that meaning for use
in the context of builtin numeric types, but there are many other uses
of these symbols that are equally consistent with their meaning.
To me, this notion of symbols with an abstract meaning which can be
narrowed for particular types by overriding magic methods is one of
Python's greatest strengths. + doesn't mean "add two numbers", it means
"add", and that makes sense for many types, and they can override
__add__ to define sensible behavior for their own purposes. [] doesn't
mean "get list item" it means "get", and types can override __getitem__
to define sensible behavior for their own purposes.
As far as I can see, these null-coalescing operators would break that
model. The PEP doesn't seem to provide for a "real" magic method
allowing users to override the actual behavior of the method. (You can
only override __has_value__ to hook into it, but not define by fiat what
A ?? B does, as you can with other operators.) And I think the reason
for this is that the operator itself is too specific, much more specific
in semantics than other operators. (I had similar doubts about adding
the matrix-multiplication operator @.)
People keep saying that this null-coalescing behavior is so common and
useful, etc., but that hasn't been my experience at all. In my
experience, the desire to shortcut this kind of logic is more often a
sign of corner-cutting and insufficiently specified data formats, and is
likely to cause bugs later on. Eventually it has to actually matter
whether something is None or not, and these operators just kick that can
down the road. In terms of their abstract meaning, they are not
remotely close to as common or useful as operators like & and |.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
