Re: [Python-ideas] .then execution of actions following a future's completion

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 wrote: > That’s very true. I’ll try to keep my terminology more in line with the >

Re: [Python-ideas] .then execution of actions following a future's completion

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)

Re: [Python-ideas] .then execution of actions following a future's completion

On Fri, Jan 26, 2018 at 9:20 AM, Daniel Collins 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

Re: [Python-ideas] .then execution of actions following a future's completion

@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

Re: [Python-ideas] .then execution of actions following a future's completion

@Guido: I agree, that’s a much cleaner solution to pass the executor. However, I think the last line should be future.add_done_callback(callback) return newf not executor.submit. I’ll rewrite it like this and resubmit tonight for discussion. Sent from my iPhone > On Jan 26, 2018, at 11:59

Re: [Python-ideas] .then execution of actions following a future's completion

@Bar: I don't know about exposing _chain_future(). Certainly it's overkill for what the OP wants -- their PR only cares about chaining concurrent.future.Future. @Daniel: I present the following simpler solution -- it requires you to explicitly pass the executor, but since 'fn' is being submitted

Re: [Python-ideas] .then execution of actions following a future's completion

Yeah, it would be better to use the chain_future call from async directly, but the problems are 1) it would make concurrent dependent on async and 2) if it were public, it would require users to instantiate futures, which they’re not supposed to do. -dancollins34 Sent from my iPhone > On Jan

Re: [Python-ideas] .then execution of actions following a future's completion

So, just going point by point: Yes, absolutely put this off for 3.8. I didn’t know the freeze was so close or I would have put the 3.8 tag on originally. Yes, absolutely it is only meant for concurrent.futures futures, it only changes async where async uses concurrent.futures futures. Here’s

Re: [Python-ideas] .then execution of actions following a future's completion

I have a simple way to solve this I believe. Why not just expose "_chain_future()" from asyncio/futures.py to the public, instead of copying and pasting parts of it? It already works, being used everywhere in the stdlib, it supports both asyncio and concurrent.futures, it's an easily testable

Re: [Python-ideas] .then execution of actions following a future's completion

I really don't want to distract Yury with this. Let's consider this (or something that addresses the same need) for 3.8. To be clear this is meant as a feature for concurrent.futures.Future, not for asyncio.Future. (It's a bit confusing since you also change asyncio.) Also to be honest I don't