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