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
>
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)
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
@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
@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
@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
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
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
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
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
Hello all,
So, first time posting here. I’ve been bothered for a while about the lack of
the ability to chain futures in python, such that the next future will execute
upon the first’s completion. So I submitted a pr to do this. This would add
the .then(self, fn) method to
11 matches
Mail list logo