Well, if we need something -- locking is better than hooks. But yes, we need a real life example. While the example is absent let's postpone the solution.
On Mon, Jun 11, 2018 at 7:50 PM Yury Selivanov <yselivanov...@gmail.com> wrote: > > 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 > <andrew.svet...@gmail.com> 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 <andrew.svet...@gmail.com> > wrote: > >> > >> 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 > > > > -- > > Thanks, > > Andrew Svetlov > > > > -- > Yury > -- 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/
