<div dir="ltr">Well, if we need something -- locking is better than hooks.<br>But yes, we need a real life example.<br>While the example is absent let's postpone the solution.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 11, 2018 at 7:50 PM Yury Selivanov <<a href="mailto:yselivanov.ml@gmail.com">yselivanov.ml@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> aiohttp doesn't depend on event loop implementation but uses public API only.<br>
<br>
Yeah, I understand. I was using it as an example of what happens if a<br>
popular library like aiohttp decides to lock the policy for whatever<br>
reason.<br>
<br>
To add to my point: event loop policies should only be used to inject<br>
a custom event loop implementation, like uvloop. They shouldn't be<br>
used to add some framework- or library-specific functionality. That's<br>
why I think that locking policies does not make a lot of sense.<br>
<br>
Yury<br>
On Mon, Jun 11, 2018 at 12:40 PM Andrew Svetlov<br>
<<a href="mailto:andrew.svetlov@gmail.com" target="_blank">andrew.svetlov@gmail.com</a>> wrote:<br>
><br>
> Sorry, smartphone is not my preferred tool.<br>
> aiohttp doesn't depend on event loop implementation but uses public API only.<br>
> aiohttp test suite allows to check against asyncio, uvloop, and tokio but it is another story.<br>
><br>
> On Mon, Jun 11, 2018 at 7:35 PM Andrew Svetlov <<a href="mailto:andrew.svetlov@gmail.com" target="_blank">andrew.svetlov@gmail.com</a>> wrote:<br>
>><br>
>> In my mind aiohttp doesn't depend on<br>
>><br>
>> On Mon, Jun 11, 2018, 19:24 Yury Selivanov <<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>> wrote:<br>
>>><br>
>>> > I want to abstract that from the user, so I tried to put that in a<br>
>>> policy. But that's dangerous since it can be changed at any time, so I<br>
>>> gave up on it and made it explicit. Of course, if the user misses that<br>
>>> in the doc (hopefully, it's an company internal code so they should be<br>
>>> trained), it will be a bummer to debug.<br>
>>><br>
>>> I still don't get it... If you have a framework you presumably have an<br>
>>> entry point. Why can't you set up your policy in that entrypoint? Why<br>
>>> would a user attempt to change the policy at runtime (you haven't<br>
>>> listed examples of libraries that do this)? I see a lot of "I want to<br>
>>> protect users from ..." arguments but I haven't yet seen "this and<br>
>>> that happened in production and we haven't been able to debug what<br>
>>> happened for a while".<br>
>>><br>
>>> Do you handle cases when people install a blocking logging handler in<br>
>>> their async application? Do you handle cases when a malfunctioning<br>
>>> sys.excepthook is installed? What about cases when users accidentally<br>
>>> import gevent somewhere in their asyncio application and it<br>
>>> monkeypatches the 'socket' module (this is a real horror story, by the<br>
>>> way)? My point is that there are so many things that users can do<br>
>>> that will break any framework, be it asyncio or django or trio.<br>
>>><br>
>>> This sounds like "if something can happen it will happen" kind of<br>
>>> thing, but I haven't yet seen good examples of real code that suffers<br>
>>> from non-locked policies. Using the nurseries example doesn't count,<br>
>>> as this is something that we want to have as a builtin functionality<br>
>>> in 3.8.<br>
>>><br>
>>> Locking policies can lead to more predictable user experience; OTOH<br>
>>> what happens if, say, aiohttp decides to lock its policy to use uvloop<br>
>>> and thus make it impossible for its users to use tokio or some other<br>
>>> loop implementation?<br>
>>><br>
>>> Yury<br>
>>><br>
>>><br>
>>><br>
>>> On Mon, Jun 11, 2018 at 4:23 AM Michel Desmoulin<br>
>>> <<a href="mailto:desmoulinmichel@gmail.com" target="_blank">desmoulinmichel@gmail.com</a>> wrote:<br>
>>> ><br>
>>> > I like it.<br>
>>> ><br>
>>> > First, it solves the issue for policies, and let people decide how they<br>
>>> > want to deal with the problem (drop the lib, subclass the<br>
>>> > policy/factory, etc).<br>
>>> ><br>
>>> > But it also solves the problem for loops, because loops are set by the<br>
>>> > task factory, and so you can easily check somebody is changing your loop<br>
>>> > from you locked policy and do whatever you want.<br>
>>> ><br>
>>> > This also solves the problem of:<br>
>>> ><br>
>>> > - task factories<br>
>>> > - event loop life cycle hooks<br>
>>> ><br>
>>> > Indeed, if somebody needs those, he/she can implement a custom loop,<br>
>>> > which can be safe guarded by the policy, which is locked.<br>
>>> ><br>
>>> > It doesn't have the drawback of my proposal of being overly general, and<br>
>>> > is quite simple to implement. But it does let people get creative with<br>
>>> > the stack.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > Python-ideas mailing list<br>
>>> > <a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
>>> > <a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
>>> > Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Yury<br>
>>> _______________________________________________<br>
>>> Python-ideas mailing list<br>
>>> <a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
>>> <a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
>>> Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
>><br>
>> --<br>
>> Thanks,<br>
>> Andrew Svetlov<br>
><br>
> --<br>
> Thanks,<br>
> Andrew Svetlov<br>
<br>
<br>
<br>
-- <br>
Yury<br>
</blockquote></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Thanks,</div>Andrew Svetlov</div></div>