[Python-ideas] Add hooks to asyncio lifecycle

[Andrew Svetlov]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180611/70302d49/attachment-0001.html>