<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 11, 2018 at 7:35 PM Andrew Svetlov <<a href="mailto:andrew.svetlov@gmail.com">andrew.svetlov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In my mind aiohttp doesn't depend on <br><br><div class="gmail_quote"><div dir="ltr">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></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> 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>
</blockquote></div>-- <br><div dir="ltr" class="m_-5554033968128819064gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Thanks,</div>Andrew Svetlov</div></div>
</blockquote></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Thanks,</div>Andrew Svetlov</div></div>