Policy locking is a viable idea at first glance. On Sun, Jun 10, 2018 at 8:05 AM Nick Coghlan <ncogh...@gmail.com> wrote:
> On 10 June 2018 at 07:59, Michel Desmoulin <desmoulinmic...@gmail.com> > wrote: > >> What I'm proposing is to make that easy to implement by just letting >> anyone put a check in there. >> >> Overriding policy, loops or tasks factories are usually down for >> critical parts of the system. The errors emerging from a bug in there >> are very cryptic. >> >> Asyncio design made the choice to expose very low level things. You >> literally don't have this problem in languages like JS because nobody >> can change those. >> >> Now it's here, it's a footgun, and it would be nice to provide a way to >> put it in a holster. >> > > With the API need framed that way, perhaps all that asyncio is currently > missing is an "asyncio.lock_policy(unlock_token, err_callback)" API such > that your application can declare that initialisation is completed and no > further event loop policy changes should be allowed? > > (The "unlock_token" would be an arbitrary app-provided object that must > also be passed to the corresponding "unlock_policy" call - that way > libraries couldn't unlock the policy after the application locks it, since > they won't have a reference to the app-specific unlock token). > > Adding further callback hooks for more events seems like it will just push > the problem back another level, and you'll have the potential for conflicts > between callbacks registered with the new hooks, and an even harder to > understand overall system. > > By contrast, the above would be amenable to doing something like: > > 1. Per-process setup code establishes a particular event loop policy, > and then locks it > 2. Until the policy gets unlocked again, attempts to change it will > call the err_callback (so the app can raise a custom access denied > exception) > 3. get_event_loop(), set_event_loop(), and new_event_loop() are all > already managed by the event loop policy, so shouldn't need new hooks > 4. stop(), close(), set_debug(), set_task_factory(), etc are all > already managed by the event loop (and hence by the event loop policy), so > shouldn't need new hooks > > Right now, the weak link in that chain is that there's no way for the > application to keep a library from switching out the event policy with a > new one, and subsequently bypassing all of the app's control over how it > expects event loops to be managed. Given a way to close that loophole, the > application should already have the ability to enforce everything else that > it wants to enforce via the existing event loop and event loop policy APIs. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > 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/
