A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2015-April/139606.html below:

[Python-Dev] PEP 492: async/await in Python; v3

[Python-Dev] PEP 492: async/await in Python; v3 [Python-Dev] PEP 492: async/await in Python; v3Ethan Furman ethan at stoneleaf.us
Wed Apr 29 07:18:58 CEST 2015
On 04/28, Guido van Rossum wrote:
> On Tue, Apr 28, 2015 at 4:55 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> On 04/28, Yury Selivanov wrote:
>>
>> >>> This limitation will go away as soon as ``async`` and ``await`` ate
>> >>> proper keywords.  Or if it's decided to use a future import for this
>> >>> PEP.
>>
>> `async` and `await` need to be proper keywords, and  __future__ imports
>> is how we do that (see, e.g., PEP 355 and and PEP 343)
>>
> 
> You could at least provide an explanation about how the current proposal
> falls short. What code will break? There's a cost to __future__ imports
> too. The current proposal is a pretty clever hack -- and we've done similar
> hacks in the past (last I remember when "import ... as ..." was introduced
> but we didn't want to make 'as' a keyword right away).

My apologies, I was unaware we had done psuedo-keywords before.

--
~Ethan~
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4