[Python-Dev] async/await in Python; v2

[Yury Selivanov]

Hi Barry,

On 2015-04-23 1:51 PM, Barry Warsaw wrote:
> On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote:
>
>> The updated version of the PEP should be available shortly at
>> https://www.python.org/dev/peps/pep-0492 and is also pasted in this email.
> There's a lot to like about PEP 492.  I only want to mildly bikeshed a bit on
> the proposed new syntax.
Thanks!
>
> Why "async def" and not "def async"?

To my eye 'async def name()', 'async with', 'async for' look
better than 'def async name()', 'with async' and 'for async'.
But that's highly subjective.

I also read "for async item in iter:" as "I'm iterating iter
with async item".

>
> My concern is about existing tools that already know that "def" as the first
> non-whitespace on the line starts a function/method definition.  Think of a
> regexp in an IDE that searches backwards from the current line to find the
> function its defined on.  Sure, tools can be updated but it is it *necessary*
> to choose a syntax that breaks tools?
>
>      def async useful():
>
> seems okay to me.
>
> Probably the biggest impact on the PEP would be symmetry with asynchronous
> with and for.  What about:
>
>      with async lock:
>
> and
>
>      for async data in cursor:
>
> That would also preserve at least some behavior of existing tools.
>
> Anyway, since the PEP doesn't explicitly describe this as an alternative, I
> want to bring it up.
>
> (I have mild concerns about __a*__ magic methods, since I think they'll be
> harder to visually separate, but here the PEP does describe the __async_*__
> alternatives.)
>
>

Anyways, I'm open to change the order of keywords if most
people like it that way.  Same for __async_*__ naming.

Thanks!
Yury