On Mon, Sep 12, 2016 at 3:13 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > From previous explanations in this thread, that's *not* the behaviour at all.
Gah, you're right. I knew better too. The diversion back to PEP 463 crossed some wires in my brain. :) > > If I understand the proposal, f is actually intended to be equivalent to: > > def f(spam): > spam_val = spam() > if spam_val is None: > return None > eggs_val = spam_val.eggs() > if eggs_val is None: > return None > return eggs_val.ham ...which is even less related to PEP 463. > > Personally, I find it pretty worrying that there's this persistent > confusion over what the proposed syntax means. Sure, it's explained in > the PEP and proposal, but if it gets implemented it'll be in the docs. > And yet people don't seem to read any of those - and their intuition > of what the construct does is wrong. The tricky bit is the syntactic association with attribute lookup. However, I don't think it's quite so confusing. As noted above, my confusion was mostly due to the recent mention of PEP 463. -eric _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/