On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan email@example.com wrote:
On 30 April 2015 at 10:21, Ethan Furman firstname.lastname@example.org 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.