peps: 5db3ad3d540b (original) (raw)
Mercurial > peps
changeset 5812:5db3ad3d540b
pep-0492: Rewrite "Why not a __future__ import" section; tx to Nick Coghlan.
| Yury Selivanov yselivanov@sprymix.com | |
|---|---|
| date | Wed, 29 Apr 2015 23🔞03 -0400 |
| parents | 552773d7e085 |
| children | ffe5f363fd88 |
| files | pep-0492.txt |
| diffstat | 1 files changed, 5 insertions(+), 8 deletions(-)[+] [-] pep-0492.txt 13 |
line wrap: on
line diff
--- a/pep-0492.txt
+++ b/pep-0492.txt
@@ -1108,14 +1108,11 @@ coroutines from regular functions visual
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"