Hm. Good point. (Though I'm not sure why that ban exists, since it's not enforceable.) Well, feel free to propose a new API for Python 3.8.
On Fri, Jan 26, 2018 at 11:23 AM, Daniel Collins <dancollin...@gmail.com> wrote: > That’s very true. I’ll try to keep my terminology more in line with the > implementation in the future. > > The only problem with that, is that the function utilizes methods that are > marked in the documentation as exclusively to be called by the executor > (set_result, instantiation of future objects) and it would be confusing if > a few lines later, a “but you can use them for this” example was provided. > > -dancollins34 > > Sent from my iPhone > > On Jan 26, 2018, at 1:05 PM, Guido van Rossum <gu...@python.org> wrote: > > On Fri, Jan 26, 2018 at 9:20 AM, Daniel Collins <dancollin...@gmail.com> > wrote: > >> @Guido As an aside, my understanding was libraries that fall back to c >> (Numpy as an example) release the GIL for load heavy operations. But I >> believe the explanation would hold in the general case if you replace >> thread with process using a ProcessPoolExecutor, that it would be good to >> be able to submit a callback function back to the executor. >> > > Sure, but your explanation didn't mention any of that. > > And yes, good catch on the last line of my example. :-) > > Given that the solution is only a few lines -- perhaps it's enough to just > add it as an example to the docs, rather than to add it as a new function > to concurrent.futures? A doc change can be added to 3.7! > > -- > --Guido van Rossum (python.org/~guido) > > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
