From c69cef2b6e1cb3e9f0d9979302b2b8e96c4d38e7 Mon Sep 17 00:00:00 2001 From: Yury Selivanov Date: Wed, 29 Apr 2015 23:18:03 -0400 Subject: [PATCH] pep-0492: Rewrite "Why not a __future__ import" section; tx to Nick Coghlan. --- pep-0492.txt | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/pep-0492.txt b/pep-0492.txt index 14de1f246..9e722ee2a 100644 --- a/pep-0492.txt +++ b/pep-0492.txt @@ -1108,14 +1108,11 @@ coroutines from regular functions visually. Why not a __future__ import --------------------------- -``__future__`` imports are inconvenient and easy to forget to add. -Also, they are enabled for the whole source file. Consider that there -is a big project with a popular module named "async.py". With future -imports it is required to either import it using ``__import__()`` or -``importlib.import_module()`` calls, or to rename the module. The -proposed approach makes it possible to continue using old code and -modules without a hassle, while coming up with a migration plan for -future python versions. +`Transition Plan`_ section explains how tokenizer is modified to treat +``async`` and ``await`` as keywords *only* in ``async def`` blocks. +Hence ``async def`` fills the role that a module level compiler +declaration like ``from __future__ import async_await`` would otherwise +fill. Why magic methods start with "a"