On 1 May 2017 at 22:02, Paul Moore <p.f.mo...@gmail.com> wrote: > On 1 May 2017 at 12:13, NoxDaFox <noxda...@gmail.com> wrote: >> >> I think it could be a good fit for the `concurrent.futures` module. >> Decorated functions would return a `Future` object and run the logic in a >> separate thread or process. >> >> >> @concurrent.futures.thread >> def function(arg, kwarg=0): >> return arg + kwarg >> >> future = function(1, kwarg=2) >> future.result() > > What's the benefit over just running the function in a thread (or > process) pool, using Executor.submit()?
It allows function designers to deliberately increase the friction of calling the function "normally". Consider an async library, for example - in such cases, it's useful to be able ensure that a blocking function never runs in the *current* thread, and instead always runs in a different one. One of the problems for the proposal is that we don't have the notion of a "default executor", the way we do with the default event loop in asyncio, so functions decorated with these would need to accept an additional parameter specifying the executor to use. 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/
