<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The actual effect of making "await" a different precedence is to resolve the ambiguity in<br><p dir="ltr">
  await x ** 2</p>
<p dir="ltr">If await acted like -, then this would be<br>
  await (x ** 2)<br>
But with the proposed grammar, it's instead<br>
  (await x) ** 2<br>
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...)</p></blockquote><div>Correct.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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<br>
  await -fut<br>
  await +fut<br>
  await ~fut<br>
become parse errors.</p></blockquote><div> 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. :-)<br></div></div><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>