[Python-ideas] Null coalescing operator

[MRAB]

On 2016-10-31 17:16, Guido van Rossum wrote:
> I think we should try to improve our intutition about these operators.
> Many things that are intuitively clear still require long turgid
> paragraphs in reference documentation to state the behavior
> unambiguously -- but that doesn't stop us from intuitively grasping
> concepts like a+b (when does b.__radd__ get called?) or @classmethod.
>
> The main case to build intuition for is "?." -- once you get that the
> "?[...]" operator works just the same. So here's my attempt:
>
> *In a series of attribute accesses like "foo.bar.baz.bletch", putting a
> `?` before a specific dot inserts a None check for the expression to the
> left and skips everything to the right when the None check is true.*
>
> We still need to clarify what we mean by "expression to the left" and
> "everything to the right", but in most situations you will guess right
> without thinking about it.
>
> The expression to the left is easy -- it's determined by syntactic
> operator precedence, so that if we have "x = y + foo.bar?.baz.bletch",
> the expression to the left of the "?." is just "foo.bar". (But see below
> -- you won't actually see such usage much.)
>
> For "everything to the right" it would seem we have some freedom: e.g.
> if we have "foo.bar?.baz(bletch)" is the call included? The answer is
> yes -- the concept we're after here is named "trailer" in the Grammar
> file in the source code
> (https://github.com/python/cpython/blob/master/Grammar/Grammar#L119),
> and "primary" in the reference manual
> (https://docs.python.org/3/reference/expressions.html#primaries). This
> means all attribute references ("x.y"), index/slice operations
> ("x[...]"), and calls ("x(...)").
>
> Note that in almost all cases the "?." operator will be used in an
> context where there is no other operator of lower precedence before or
> after it -- given the above meaning, it doesn't make a lot of sense to
> write "1 + x?.a" because "1 + None" is always an error (and ditto for
> "x?.a + 1"). However it still makes sense to assign such an expression
> to a variable or pass it as an argument to a function.
>
> So you can ignore the preceding four paragraphs: just remember the
> simplified rule (indented and in bold, depending on your email client)
> and let your intuition do the rest. Maybe it can even be simplified more:
>
> *The "?." operator splits the expression in two parts; the second part
> is skipped if the first part is None.
> *
>
> Eventually this *will* become intuitive. The various constraints are all
> naturally imposed by the grammar so you won't have to think about them
> consciously.
>
Would it help if we referred to them collectively as "suffixes"?

Coincidentally, David Mertz's post includes a case where this feature 
would shorten the code.

In normal Python form his code has:

     if x in stop_on or (end_if and end_if(x)):

With this feature it could be:

     if x in stop_on or end_if?(x):