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):
_______________________________________________
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
