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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
