[Python-ideas] Add hooks to asyncio lifecycle

Andrew Svetlov andrew.svetlov at gmail.com
Mon Jun 11 12:35:30 EDT 2018


In my mind aiohttp doesn't depend on

On Mon, Jun 11, 2018, 19:24 Yury Selivanov <yselivanov.ml at gmail.com> wrote:

> > 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?
>
> Yury
>
>
>
> 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/
>
>
>
> --
>          Yury
> _______________________________________________
> 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/
>
-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180611/0dd32a92/attachment.html>


More information about the Python-ideas mailing list