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. --Guido On Mon, Oct 31, 2016 at 9:33 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 31 October 2016 at 15:51, Mark E. Haase <mehaase@gmail.com> wrote:
Therefore, I have updated the PEP with the punctuation mentioned above, and at this point the PEP can't go any farther. If the best spelling for this new operator is unacceptable, then there's no getting around that. This PEP should be rejected.
While I agree that there's little point arguing over spelling here - if the ? spelling is unacceptable we should just reject - I'm not sure that's the only sticking point remaining here. I still find the short-circuiting behaviour of ?. (and ?[) to be pretty confusing - and the fact that there's a long paragraph describing the behaviour, with lots of examples of the form "if you think that this example works like so, then you're wrong, and it actually does the following", suggests to me that I'm not going to be the only one struggling. Hopefully, the problem is simply the way the behaviour is presented, and a reworking of the description would make it all crystal clear - but it feels to me that there's some inherent complexity here that's an actual issue with the proposal.
Having said that, it appears that the proposed behaviour is the same as in C# (can you just come out and say "C#", rather than hinting with the phrase "other popular languages" - if we're stealing the behaviour as is from C#, let's say so, and if not, can you include examples from more than one language?) Assuming that's the case, then the fact that it's not causing confusion to C# programmers is a definite point in its favour.
Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)