On 31 October 2016 at 17:16, Guido van Rossum <guido@python.org> 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 "?." 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.
Thanks. Yes, I agree that details in a spec are never particularly obvious, and we need an intuition of what the operator does if it's to be successful. Mark - I couldn't offer a specific rewording, precisely because I found the whole thing confusing. But based on Guido's post, I'd say that the "intuitive" explanation of the proposed operators should be right at the top of the PEP, in the abstract - and should be repeated as the first statement in the specification section for each operator. The details can then follow, including all of the corner cases. But I'd be inclined there to word the corner cases as positive statements, rather than negative ones. Take for example, the case "d?.year.numerator + 1" - you say """ Note that the error in the second example is not on the attribute access numerator . In fact, that attribute access is never performed. The error occurs when adding None + 1 , because the None -aware attribute access does not short circuit + . """ which reads to me as presenting the misconception (that the error was from the access to numerator) before the correct explanation, and then explaining to the reader why they were confused if they thought that. I'd rather see it worded something along the lines of: """
d = date.today() d?.year.numerator + 1 2016
d = None d?.year.numerator + 1
Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' Note that the second example demonstrates that when ?. splits the enclosing expression into 2 parts, operators like + have a lower precedence, and so are not short circuited. So, we get a TypeError if d is None, because we're trying to add None to an integer (as the error states). """ There's no need to even *mention* the incorrect interpretation, it does nothing for people who'd misinterpreted the example in the first place, but for people who hadn't, it just suggests to them an alternative explanation they hadn't thought of - so confusing them where they weren't confused before. Does this clarify what I was struggling with in the way the PEP was worded? Paul