Out of curiosity, how much of a breaking change would making unary
operators stack arbitrarily be?
On 4/30/2015 23:57, Nathaniel Smith wrote:
On Apr 30, 2015 8:40 PM, "Guido van Rossum" <gu...@python.org
<mailto:gu...@python.org>> wrote:
>
> On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith <n...@pobox.com
<mailto: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/tritium-list%40sdamon.com
_______________________________________________
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
