https://hg.python.org/peps/rev/5db3ad3d540b changeset: 5812:5db3ad3d540b user: Yury Selivanov <yselivanov@sprymix.com> date: Wed Apr 29 23:18:03 2015 -0400 summary: pep-0492: Rewrite "Why not a __future__ import" section; tx to Nick Coghlan. files: pep-0492.txt | 13 +++++-------- 1 files changed, 5 insertions(+), 8 deletions(-) diff --git a/pep-0492.txt b/pep-0492.txt --- a/pep-0492.txt +++ b/pep-0492.txt @@ -1108,14 +1108,11 @@ 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" -- Repository URL: https://hg.python.org/peps