[Python-ideas] Add hooks to asyncio lifecycle

Yury Selivanov yselivanov.ml at gmail.com
Mon Jun 11 12:23:21 EDT 2018

> I want to abstract that from the user, so I tried to put that in a
policy. But that's dangerous since it can be changed at any time, so I
gave up on it and made it explicit. Of course, if the user misses that
in the doc (hopefully, it's an company internal code so they should be
trained), it will be a bummer to debug.

I still don't get it... If you have a framework you presumably have an
entry point. Why can't you set up your policy in that entrypoint?  Why
would a user attempt to change the policy at runtime (you haven't
listed examples of libraries that do this)?  I see a lot of "I want to
protect users from ..." arguments but I haven't yet seen "this and
that happened in production and we haven't been able to debug what
happened for a while".

Do you handle cases when people install a blocking logging handler in
their async application?  Do you handle cases when a malfunctioning
sys.excepthook is installed?  What about cases when users accidentally
import gevent somewhere in their asyncio application and it
monkeypatches the 'socket' module (this is a real horror story, by the
way)?  My point is that there are so many things that users can do
that will break any framework, be it asyncio or django or trio.

This sounds like "if something can happen it will happen" kind of
thing, but I haven't yet seen good examples of real code that suffers
from non-locked policies.  Using the nurseries example doesn't count,
as this is something that we want to have as a builtin functionality
in 3.8.

Locking policies can lead to more predictable user experience; OTOH
what happens if, say, aiohttp decides to lock its policy to use uvloop
and thus make it impossible for its users to use tokio or some other
loop implementation?


On Mon, Jun 11, 2018 at 4:23 AM Michel Desmoulin
<desmoulinmichel at gmail.com> wrote:
> I like it.
> First, it solves the issue for policies, and let people decide how they
> want to deal with the problem (drop the lib, subclass the
> policy/factory, etc).
> But it also solves the problem for loops, because loops are set by the
> task factory, and so you can easily check somebody is changing your loop
> from you locked policy and do whatever you want.
> This also solves the problem of:
> - task factories
> - event loop life cycle hooks
> Indeed, if somebody needs those, he/she can implement a custom loop,
> which can be safe guarded by the policy, which is locked.
> It doesn't have the drawback of my proposal of being overly general, and
> is quite simple to implement. But it does let people get creative with
> the stack.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/


More information about the Python-ideas mailing list