<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Out of curiosity, how much of a breaking change would making unary
    operators stack arbitrarily be?<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 4/30/2015 23:57, Nathaniel Smith
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAPJVwBn-ouipE0cW61Lw_9VNOPDbSqwzdmuC1L-0U-iLegizdQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <p dir="ltr">On Apr 30, 2015 8:40 PM, "Guido van Rossum" <<a
            moz-do-not-send="true" href="mailto:guido@python.org"
            target="_blank">guido@python.org</a>> wrote:<br>
          ><br>
          > On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith <<a
            moz-do-not-send="true" href="mailto:njs@pobox.com"
            target="_blank">njs@pobox.com</a>> wrote:<br>
          >><br>
          >> The actual effect of making "await" a different
          precedence is to resolve the ambiguity in<br>
          >><br>
          >>   await x ** 2<br>
          >><br>
          >> 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...)<br>
          ><br>
          > Correct.<br>
          >><br>
          >> 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>
          >><br>
          >>   await -fut<br>
          >>   await +fut<br>
          >>   await ~fut<br>
          >> become parse errors.<br>
          ><br>
          >  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. :-)</p>
        <p dir="ltr">I didn't say it was regrettable, I said it was
          arguably regrettable. For proof, see the last week of
          python-dev ;-).<br>
        </p>
        <p>(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.)<br>
        </p>
        <p>-n<br>
        </p>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Python-Dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Python-Dev@python.org">Python-Dev@python.org</a>
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/options/python-dev/tritium-list%40sdamon.com">https://mail.python.org/mailman/options/python-dev/tritium-list%40sdamon.com</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>