> 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/
