[Python-Dev] PEP 492 vs. PEP 3152, new round (original) (raw)

Alexander Walters tritium-list at sdamon.com
Fri May 1 06:01:53 CEST 2015

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>

More information about the Python-Dev mailing list