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/139513.html below:

[Python-Dev] PEP 492 vs. PEP 3152, new round

[Python-Dev] PEP 492 vs. PEP 3152, new roundYury Selivanov yselivanov.ml at gmail.com
Fri Apr 24 23:36:49 CEST 2015
Victor,

On 2015-04-24 5:32 PM, Victor Stinner wrote:
>> 7. compatibility with asyncio and existing users of it
> The current state of the PEP makes types.coroutine() mandatory. If a
> generator-based coroutine is not modified with types.coroutine, await
> cannot be used on it. To be more concrete: asyncio coroutines not
> declared with @asyncio.coroutine cannot be used with await.
>
> Would it be crazy to allow waiting on a generator-based coroutine
> (current asyncio coroutines) without having to call types.coroutine()
> on it?

I'd be big -1 on that.  The current PEP design is all about
strictly prohibiting users from calling regular generators
with 'await' expression.  And if a generator isn't decorated
with @coroutine - then it's a regular generator for us.

>
> Maybe I just missed the purpose of disallow this.
>
> It's also possible to modify asyncio to detect at runtime when an
> asyncio coroutine is not decorated by @asyncio.coroutine (emit a
> warning or even raise an exception).

I'd be +1 to add a warning to Task and other places where
we accept generator-based coroutines.

Thanks!
Yury

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