On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 30 April 2015 at 10:21, Ethan Furman <ethan@stoneleaf.us> wrote:
> From the PEP:
>
>> Why not a __future__ import
>>
>> __future__ imports are inconvenient and easy to forget to add.
>
> That is a horrible rationale for not using an import.  By that logic we
> should have everything in built-ins.  ;)

This response is silly. The point is not against import but against __future__. A __future__ import definitely is inconvenient -- few people I know could even recite the correct constraints on their placement.
 
It is also makes things more painful than they need to be for syntax
highlighters.

Does it? Do highlighters even understand __future__ imports? I wouldn't mind if a highlighter always highlighted 'async' and 'await' as keywords even where they aren't yet -- since they will be in 3.7.
 
'as' went through the "not really a keyword" path, and
it's a recipe for complexity in the code generation toolchain and
general quirkiness as things behave in unexpected ways.

I don't recall that -- but it was a really long time ago so I may misremember (did we even have __future__ at the time?).
 
We have a defined process for introducing new keywords (i.e.
__future__ imports) and the PEP doesn't adequately make the case for
why we shouldn't use it here.

That's fair. But because of the difficulty in introducing new keywords, many proposals have been shot down or discouraged (or changed to use punctuation characters or abuse existing keywords) -- we should give Yury some credit for figuring out a way around this. Honestly I'm personally on the fence.

--
--Guido van Rossum (python.org/~guido)