[Python-ideas] Add hooks to asyncio lifecycle

[Yury Selivanov]

> 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