[Python-ideas] Add hooks to asyncio lifecycle

[Yury Selivanov]

On Tue, Jun 12, 2018 at 5:34 AM Michel Desmoulin
<desmoulinmichel at gmail.com> wrote:
[..]
> But even if I have spoken up then, my experience with Python-idea is
that most of the time, people would have told me "no". They would have
told me that "nobody is going to do that".

> I'm getting used to it. It took me a lot of time of "path should inherit
from strings" to finally have enough people involved that we get a
solution to the problem (which ended up being __fspath__). At the
beginning, the answer was "no, there is no problem".

> So basically, now I speak up, knowing that people will say "no". But at
least I said it. Maybe in 2 years we will go back to that an implement
it, or another solution to this problem.

[..]
> Locking the policy is providing a clean and easy way to do things.

Michel,

I know you're an avid asyncio user.  I've seen your kind comments
about asyncio and uvloop on reddit, twitter, etc.  So I really don't
want to discourage you from posting here and proposing ideas.  But
arguments like 'people would have told me "no" ... I'm getting used to
it.' aren't helpful.

I've repeatedly asked you in this thread to provide a couple of good
and easy to follow examples so that we can make an informed decision
about whether we should add policy locking mechanism or not.

Example:  We want to create library "A" because it will work only with
event loop "B".  Checking the event loop once in A's APIs doesn't work
[because ...].  Another example: We use asyncio in production and we
see that people change policies at runtime all the time; we need to
guard against that somehow.

Unless you can clearly demonstrate that locking solves real world
problems we are not going to implement it, because get_event_loop()
and policies are *already* too complicated.  You say that Django
performs a bunch of sanity checks, but I don't see a good explanation
of why you can't just call
`isinstance(asyncio.get_event_loop_policy())` in your
framework/application.

I also keep repeating that libraries, in general, shouldn't be
hardcoded to work with some specific policies, and they should not
provide alternative policies unless they provide an alternative event
loop implementation. And I don't want to add locking to somehow
encourage libraries to use policies.  I use a bunch of asyncio
libraries in my code and none of them (except aiohttp) uses policies.
And aiohttp provides policies only to help you run HTTP servers under
gunicorn etc, it's up to the user if they want to use them or not.

I'm currently prototyping nurseries/cancel scopes for asyncio and I
don't need to use policies to make them work. So I honestly don't see
a clear case to add locking so far. Maybe having a PEP would allow us
to build a compelling case for adding policies locking.

Yury