[Python-Dev] PEP 492 vs. PEP 3152, new round

[Alexander Walters]

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>