[Python-checkins] peps: pep-0492: Rewrite "Why not a __future__ import" section; tx to Nick Coghlan.
yury.selivanov
python-checkins at python.org
Thu Apr 30 05:18:06 CEST 2015
https://hg.python.org/peps/rev/5db3ad3d540b
changeset: 5812:5db3ad3d540b
user: Yury Selivanov <yselivanov at 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
More information about the Python-checkins
mailing list