[Python-ideas] Add hooks to asyncio lifecycle

Andrew Svetlov andrew.svetlov at gmail.com
Mon Jun 11 12:55:39 EDT 2018


Well, if we need something -- locking is better than hooks.
But yes, we need a real life example.
While the example is absent let's postpone the solution.

On Mon, Jun 11, 2018 at 7:50 PM Yury Selivanov <yselivanov.ml at gmail.com>
wrote:

> > aiohttp doesn't depend on event loop implementation but uses public API
> only.
>
> Yeah, I understand.  I was using it as an example of what happens if a
> popular library like aiohttp decides to lock the policy for whatever
> reason.
>
> To add to my point: event loop policies should only be used to inject
> a custom event loop implementation, like uvloop.  They shouldn't be
> used to add some framework- or library-specific functionality.  That's
> why I think that locking policies does not make a lot of sense.
>
> Yury
> On Mon, Jun 11, 2018 at 12:40 PM Andrew Svetlov
> <andrew.svetlov at gmail.com> wrote:
> >
> > Sorry, smartphone is not my preferred tool.
> > aiohttp doesn't depend on event loop implementation but uses public API
> only.
> > aiohttp test suite allows to check against asyncio, uvloop, and tokio
> but it is another story.
> >
> > On Mon, Jun 11, 2018 at 7:35 PM Andrew Svetlov <andrew.svetlov at gmail.com>
> wrote:
> >>
> >> 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
> >
> > --
> > Thanks,
> > Andrew Svetlov
>
>
>
> --
>          Yury
>
-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180611/555eb18f/attachment-0001.html>


More information about the Python-ideas mailing list