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

[Isaac Schwabacher]

On 15-04-29, Yury Selivanov  wrote:
> Hi Ethan,
> 
> On 2015-04-29 2:32 PM, Ethan Furman wrote:
> >On 04/29, Yury Selivanov wrote:
> >>On 2015-04-29 1:25 PM, Ethan Furman wrote:
> >>>cannot also just work and be the same as the parenthesized
> >>>version.
> >>Because it does not make any sense.
> >I obviously don't understand your position that "it does not make
> >any sense" -- perhaps you could explain a bit?
> >
> >What I see is a suspension point that is waiting for the results of
> >coro(), which will be negated (and returned/assigned/whatever).
> >What part of that doesn't make sense?
> >
> 
> Because you want operators to be resolved in the
> order you see them, generally.
> 
> You want '(await -fut)' to:
> 
> 1. Suspend on fut;
> 2. Get the result;
> 3. Negate it.
> 
> This is a non-obvious thing. I would myself interpret it
> as:
> 
> 1. Get fut.__neg__();
> 2. await on it.
> 
> So I want to make this syntactically incorrect:

Does this need to be a syntax error? -"hello" raises TypeError because str doesn't have a __neg__, but there's no reason a str subclass couldn't define one. "TypeError: bad operand type for unary -: 'asyncio.Future'" is enough to clear up any misunderstandings, and if someone approaching a new language construct doesn't test their code well enough to at least execute all the code paths, the difference between a compile-time SyntaxError and a run-time TypeError is not going to save them.

ijs

> 'await -fut' would throw a SyntaxError. To do what you
> want, write a pythonic '- await fut'.
> 
> 
> Yury
> 
> _______________________________________________
> 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/ischwabacher%40wisc.edu