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

Isaac Schwabacher ischwabacher at wisc.edu
Wed Apr 29 21:24:57 CEST 2015

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

More information about the Python-Dev mailing list