[Python-ideas] Add hooks to asyncio lifecycle

Michel Desmoulin desmoulinmichel at gmail.com
Sat Jun 9 17:59:30 EDT 2018

> IMHO, it is not any framework's job to check for this.  It is a
> programmer error.  

Not clearing the memory is a programmer error either but a gc helps.

Not closing a file either but using `with` help.

Not passing the proper type is a programmer error but we have type hints.

We even have assert that we can be disabled to check that the arguments
of a function match a test when debugging.

You don't need to babysit programmers so much. 

Helping to debug is not babysitting. It's a important part of the user
experience, and it's especially needed on asyncio, one of the hardest
part of the stdlib to code with.

Not if the cost is adding new APIs.

The cost of bugs is greater than the cost of API. The current API gives
no sane way to prevent the bug. You can't expect anyone to check if the
policy / loop / task factory has changed every single time in the code
you depend on it.

> I agree with Andrew, if we open this precedent, next thing we know,
> Python has to provide callbacks for any internal state changes.

It's not internal, it's a public API.

  Why not
> callbacks for when modules are imported?

Good example.

We have import hooks to run code every time a module is imported :


 Etc. etc.  It leads to API
> noise.  

Every features is either useful or noise. I argue that this one is useful.

Doesn't seem to be justified in this case, since I would guess
> almost all applications only change event loop policy once, during
> startup, and never again.

Yes, but when is start up ?

E.G: I'm currently working on a large QT api on an old 2.7 code base. It
has threads to avoid blocking the UI, qt events loops of course and the
tornado events loop providing a web API. The orchestration of that very
complex app requires careful initialization for a start up time of about
7s, and we had to code some wrapper and document it as the only entry
point to make sure that if a junior breaks things the error message is
very clear.

RuntimeError('The event loop should not be set when...') is way easier
to debug than an obscure down the road error on some data structure that
is incorrectly accessed.

What I'm proposing is to make that easy to implement by just letting
anyone put a check in there.

Overriding policy, loops or tasks factories are usually down for
critical parts of the system. The errors emerging from a bug in there
are very cryptic.

Asyncio design made the choice to expose very low level things. You
literally don't have this problem in languages like JS because nobody
can change those.

Now it's here, it's a footgun, and it would be nice to provide a way to
put it in a holster.

More information about the Python-ideas mailing list