On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 30 April 2015 at 10:21, Ethan Furman <et...@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)
_______________________________________________ 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
