> 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 <[email protected]> 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 <[email protected]> > wrote: >> >> In my mind aiohttp doesn't depend on >> >> On Mon, Jun 11, 2018, 19:24 Yury Selivanov <[email protected]> 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 >>> <[email protected]> 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 >>> > [email protected] >>> > https://mail.python.org/mailman/listinfo/python-ideas >>> > Code of Conduct: http://python.org/psf/codeofconduct/ >>> >>> >>> >>> -- >>> Yury >>> _______________________________________________ >>> Python-ideas mailing list >>> [email protected] >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> -- >> Thanks, >> Andrew Svetlov > > -- > Thanks, > Andrew Svetlov -- Yury _______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
