[Python-ideas] Proposed alternative postfix syntax [was PEP 505: None-aware operators]

David Mertz mertz at gnosis.cx
Sun Jul 29 10:00:46 EDT 2018


On Sun, Jul 29, 2018, 7:46 AM Steven D'Aprano <steve at pearwood.info> wrote:

> One of the problems with David Mertz's counter-proposal for a magic
> None-aware proxy is that we can't tell the difference between  spam.eggs
> and spam.eggs where one of them is magic and the other is not. So we have a
> nice, clear, obvious difference in syntax so that at a glance the reader
> can instantly distinguish between dot and maybe-dot, and you are
> complaining that it is too clear, obvious and easily distinguishable
> compared to a regular dot.
>

That's exactly the strongest advantage in what I suggest!

The special domain where you want attribute access (or dictionary lookup)
to be None coalescing is something marked and different from most of what
you want in general attribute access. But once you're in that special world
of "semi-structured hierarchical data with leaves marked with None" you
don't want to be reminded in every operator. It's just what you do with
that kind of object.

Naming variable might be a good way to remind readers of the domain. Or
comments in the source code. Or putting the special behavior in an isolated
function. But effectively, this is a domain you want to enter for a while,
then return to the "real world" after some operations are done.

For a pretty good analogy, you cannot tell the difference between 'a+b' and
'a+b' easily either, in isolation.  But one of those is arithmetic over the
domain of integers, while the other is arithmetic over the domain of a
Z(65537) modular ring. Many operations are the same in both domains, but
I'd really hate to need a special operator to perform modular arithmetic
rather than integer arithmetic.  E.g. 'a + b' vs 'a ⊕ b'.

It is MUCH more elegant and clear in both examples to put the work on the
*object* that has special behavior, not on the operator. I can see that if
you did a very special kind of programming where you frequently mixed
modular and integer arithmetic, you might want the reminder. But that's a
rare need, and the language itself should not grow that syntax (perhaps
something specialized like Sage or Octave might want a different balance,
very reasonably).

"Semi-structured hierarchical data with leafs marked with None" is just
altogether too special to impose the burden all Python programmers. A
None-aware proxy isn't the best possible thing for that special use by any
means. But it's pretty good without imposing any burden on the large
majority who will never need or use it.

Another similar case is the '@' operator. This is exactly a special domain
where an operator indicates special behavior. In principle, you could make
objects that did anything whatsoever when they see that, but the name
.__matmul__ is pretty suggestive of recommended use. However, nothing in
the builtins or standard library define any behavior at all. You can
happily program with Python your whole life and never think about this
operator. The only folks who will see it are folks who use NumPy and *also*
do linear algebra with it. By definition, the objects if this domain are
already special, as it should be.

Well, footnote. I think I've seen some other libraries that create a DSL
around email that use '@' also. That also feels fine. It's a very
different, but equally special, domain where the objects themselves define
the special behavior.

If PEP 505 were proposing a regular new protocol for .__none_attr__() or
some better dunder name, I would oppose it far less. Specifically, if the
behavior of this dunder operator were left to library authors who created
such special objects, the danger and bug-magneticism would be much less.
I'm well aware that dunders can't get you shortcutting, but modulo that,
such a proposal would be relatively innocuous (I'd still be -0, but not
really care).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180729/c743c7b4/attachment-0001.html>


More information about the Python-ideas mailing list