[Python-Dev] PEP 492 quibble and request

[Guido van Rossum]

Belt and suspenders. :-)

We may need help with the implementation though -- PEP 479 is still waiting
on implementation help with __future__ too AFAIK.

On Wed, Apr 29, 2015 at 8:01 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 30 April 2015 at 12:31, Guido van Rossum <guido at python.org> wrote:
> > On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan <ncoghlan at gmail.com>
> wrote:
> >>
> >> [...]
> >> Yeah, I'm coming around to the idea. For the async pseudo-keyword, I
> >> can see that the proposal only allows its use in cases that were
> >> previously entirely illegal, but I'm not yet clear on how the PEP
> >> proposes to avoid changing the meaning of the following code:
> >>
> >>     x = await(this_is_a_function_call)
> >>
> >> Unless I'm misreading the proposed grammar in the PEP (which is
> >> entirely possible), I believe PEP 492 would reinterpret that as:
> >>
> >>     x = await this_is_not_a_function_call_any_more
> >
> >
> > Ah, but here's the other clever bit: it's only interpreted this way
> *inside*
> > a function declared with 'async def'. Outside such functions, 'await' is
> not
> > a keyword, so that grammar rule doesn't trigger. (Kind of similar to the
> way
> > that the print_function __future__ disables the keyword-ness of 'print',
> > except here it's toggled on or off depending on whether the nearest
> > surrounding scope is 'async def' or not. The PEP could probably be
> clearer
> > about this; it's all hidden in the Transition Plan section.)
>
> Ah, nice, although even reading the Transition Plan section didn't
> clue me in to that particular aspect of the idea :)
>
> Given that clarification, I think the rationale for "no __future__
> statement needed" can be strengthened by focusing on the fact that
> such a statement would largely be *redundant*, given that:
>
> * "async def", "async with", and "async for" are all currently syntax
> errors, and hence adding them is backwards compatible if "async" is
> otherwise treated as a normal variable name
> * "await <expr>" only gains its new interpretation when used inside an
> "async def" statement, so "async def" fills the role that a module
> level compiler declaration like "from __future__ import
> async_functions" would otherwise fill
>
> That said, it may be worth having the future statement *anyway* as:
>
> 1. It gives us the runtime accessible record of the feature transition
> in the __future__ module
> 2. It lets folks opt-in to the full keyword implementation from day 1
> if they prefer, addressing the tokenisation limitation noted in the
> PEP:
> https://www.python.org/dev/peps/pep-0492/#transition-period-shortcomings
>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150429/bf0a69f6/attachment-0001.html>