<div dir="ltr"><div>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.<br><br>The main case to build intuition for is "?." -- once you get that the "?[...]" operator works just the same. So here's my attempt:<br><br><div style="margin-left:40px"><b>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.</b><br></div><br>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.<br><br>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.)<br></div><div><br>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 (<a href="https://github.com/python/cpython/blob/master/Grammar/Grammar#L119">https://github.com/python/cpython/blob/master/Grammar/Grammar#L119</a>), and "primary" in the reference manual (<a href="https://docs.python.org/3/reference/expressions.html#primaries">https://docs.python.org/3/reference/expressions.html#primaries</a>). This means all attribute references ("x.y"), index/slice operations ("x[...]"), and calls ("x(...)").<br><br>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.<br><br></div><div>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:<br><br><div style="margin-left:40px"><b>The "?." operator splits the expression in two parts; the second part is skipped if the first part is None.<br></b></div></div><div><br></div><div>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.<br><br></div><div>--Guido<br></div><div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 31, 2016 at 9:33 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 31 October 2016 at 15:51, Mark E. Haase <<a href="mailto:mehaase@gmail.com">mehaase@gmail.com</a>> wrote:<br>
> Therefore, I have updated the PEP with the punctuation mentioned above, and<br>
> at this point the PEP can't go any farther. If the best spelling for this<br>
> new operator is unacceptable, then there's no getting around that. This PEP<br>
> should be rejected.<br>
<br>
While I agree that there's little point arguing over spelling here -<br>
if the ? spelling is unacceptable we should just reject - I'm not sure<br>
that's the only sticking point remaining here. I still find the<br>
short-circuiting behaviour of ?. (and ?[) to be pretty confusing - and<br>
the fact that there's a long paragraph describing the behaviour, with<br>
lots of examples of the form "if you think that this example works<br>
like so, then you're wrong, and it actually does the following",<br>
suggests to me that I'm not going to be the only one struggling.<br>
Hopefully, the problem is simply the way the behaviour is presented,<br>
and a reworking of the description would make it all crystal clear -<br>
but it feels to me that there's some inherent complexity here that's<br>
an actual issue with the proposal.<br>
<br>
Having said that, it appears that the proposed behaviour is the same<br>
as in C# (can you just come out and say "C#", rather than hinting with<br>
the phrase "other popular languages" - if we're stealing the behaviour<br>
as is from C#, let's say so, and if not, can you include examples from<br>
more than one language?) Assuming that's the case, then the fact that<br>
it's not causing confusion to C# programmers is a definite point in<br>
its favour.<br>
<br>
Paul<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>