On Apr 30, 2015 8:40 PM, "Guido van Rossum" <gu...@python.org> wrote: > > On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith <n...@pobox.com> wrote: >> >> The actual effect of making "await" a different precedence is to resolve the ambiguity in >> >> await x ** 2 >> >> If await acted like -, then this would be >> await (x ** 2) >> But with the proposed grammar, it's instead >> (await x) ** 2 >> Which is probably correct, and produces the IMHO rather nice invariant that "await" binds more tightly than arithmetic in general (instead of having to say that it binds more tightly than arithmetic *except* in this one corner case...) > > Correct. >> >> AFAICT these and the ** case are the only expressions where there's any difference between Yury's proposed grammar and your proposal of treating await like unary minus. But then given the limitations of Python's parser plus the desire to disambiguate the expression above in the given way, it becomes an arguably regrettable, yet inevitable, consequence that >> >> await -fut >> await +fut >> await ~fut >> become parse errors. > > Why is that regrettable? Do you have a plan for overloading one of those on Futures? I personally consider it a feature that you can't do that. :-)
I didn't say it was regrettable, I said it was arguably regrettable. For proof, see the last week of python-dev ;-). (I guess all else being equal it would be nice if unary operators could stack arbitrarily, since that really is the more natural parse rule IMO and also if things had worked that way then I would have spent this thread less confused. But this is a pure argument from elegance. In practice there's obviously no good reason to write "await -fut" or "-not x", so meh, whatever.) -n
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
