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" <guido at python.org > <mailto:guido at python.org>> wrote: > > > > On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith <njs at pobox.com > <mailto:njs at 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 at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium-list%40sdamon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150501/a24d73d0/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4