Isn't buffersize empty? Can you introduce it? (Forgive me for not understanding it).

absolutely np, thank you for taking the time to review my proposal. To be sure to understand the question well, what do you mean by"Isn't buffersize empty?"

Hey@rruuaanng , I have reworked the PR's description, I hope it makes things clearer!

args may be empty, so you need to check forargs is not None

Are you refering to the case where one callexecutor.map(func) without any input iterable?

Yes. You can't always assume thatfunc needs an input (or do you?)

you are right! But in such a case we don't enter thewhile fs: (fs being empty in that case), right?

@picnixz I have added unit tests checking the behavior with multiple input iterables and without any input iterables.

But in such a case we don't enter the while fs.

Not necessarily. What I meant is that you callexecutor.map with an input iterable that yieldsargs = () everytime.

Note that it also doesn't hurt to checkis not None because it's probably slightly faster since otherwise you need to call__bool__ on the args being yielded.

So for example a call likeexecutor.map(func, [()])? In such a call we getiterables = ([()],) andargs_iter = iter(zip(*([()],))) andnext(args_iter,) will be((),) (not()). You may have missed theziping in your reasoning?

In term of pure readability of the code I struggle to have an opinion, do you feel that(args := next(args_iter, None)) is not None is more natural?

You may have missed the ziping in your reasoning?

I did :) Sorry, my bad!

do you feel that (args := next(args_iter, None)) is not None is more natural?

I feel it would at least help avoiding questions like mine! (and it would still be probably slightly better performance wise but this claim is just my gut feeling).

@picnixz oh yes I see... I have renamedargs_iter into a more self-explanatoryzipped_iterables, do you think it would be enough to avoid the confusion?

(Because I am scared that the addition ofis not None may misslead some of our fellow pythonistas wondering "wait, why is this not None check necessary here, what am I missing here 🤔?")

Personally, I like having theis not None just so that I don't have to wonder what'sargs_iter is precisely yielding. I can assume that it's yielding a tuple-like object, but I don't necessarily know the shape of that tuple. Sois not None discriminates probable items and the sentinel value. So I'd say it's still pythonic.

Performance-wise it should be roughly the same (one checks that the tuple's size != 0 and the other just compares if it's the None singleton but both are essentially a single comparison).

Now up to you. If others didn't observe (like me) thatargs_iter never yields an empty tuple, then it's probably better to keep theis not None check for clarity.

Are you refering to the case where one callexecutor.map(func) without any input iterable?

@ebonnal I believe you got this part slightly wrong, "off-by-one". IIUC, the number of pending futures cannot be larger thanbuffsize. However, after the initial submission ofbuffsize tasks before, here in this branch you are appending an EXTRA task to the queue, and now you havebuffsize + 1 tasks that have potentially not yielded yet.

Fortunately, looks like the fix is trivial: you simply have to yield first, next append to the queue:

diff --git a/Lib/concurrent/futures/_base.py b/Lib/concurrent/futures/_base.pyindex d98b1ebdd58..3b9ccf4d651 100644--- a/Lib/concurrent/futures/_base.py+++ b/Lib/concurrent/futures/_base.py@@ -628,17 +628,17 @@ def result_iterator():                 # reverse to keep finishing order                 fs.reverse()                 while fs:+                    # Careful not to keep a reference to the popped future+                    if timeout is None:+                        yield _result_or_cancel(fs.pop())+                    else:+                        yield _result_or_cancel(fs.pop(), end_time - time.monotonic())                     if (                         buffersize                         and (executor := executor_weakref())                         and (args := next(zipped_iterables, None))                     ):                         fs.appendleft(executor.submit(fn, *args))-                    # Careful not to keep a reference to the popped future-                    if timeout is None:-                        yield _result_or_cancel(fs.pop())-                    else:-                        yield _result_or_cancel(fs.pop(), end_time - time.monotonic())             finally:                 for future in fs:                     future.cancel()

Hi@dalcinl,

TL;DR: fyi we have#131467 that is open and tackling this "off-by-one" situation. Would be great to get your review there! 🙏🏻
I have not proposed this variation at first because I think it makes sense as an optional follow up PR given that it integrates slightly less smoothly into existing logic.

You will notice that it is not "just" moving the yield before the enqueue, let's see why on a simple scenario, explaining the 3 behaviors:

Scenario:

it=executor.map(fn,iterable,buffersize=buffersize)# point Anext(it)# point Bnext(it)# point C

"enqueue -> wait -> yield" (current, introduced by this PR) behavior

• buffersbuffersize tasks
• at# point A there isbuffersize buffered tasks
• 1st call tonext:
  • enqueue a task, jumping tobuffersize+1 tasks in buffer
  • wait for the next result to be available
  • yield the next result, finally going down tobuffersize tasks in buffer
• at# point B there is stillbuffersize buffered tasks
• 2nd call tonext: same

pro:buffersize tasks in buffer between two calls tonext
con: while waiting for the next result we havebuffersize+1 tasks in buffer

"wait -> yield -> enqueue" (your proposal) behavior

• buffersbuffersize tasks
• at# point A there isbuffersize buffered tasks
• call tonext:
  • wait for the next result to be available
  • yield this result, going down tobuffersize - 1 tasks in buffer
• at# point B there isbuffersize - 1 buffered tasks
• call tonext:
  • enqueue a task, jumping back tobuffersize tasks in buffer
  • wait for the next result to be available
  • yield next result, going down tobuffersize - 1 tasks in buffer
• at# point C there is stillbuffersize-1 buffered tasks

pro: never exceedbuffersize
con: between two calls tonext we have onlybuffersize - 1 tasks in buffer

"wait -> enqueue -> yield" (#131467) behavior

• buffersbuffersize tasks
• at# point A there isbuffersize buffered tasks
• 1st call tonext:
  • wait for next result to be available
  • enqueue a task, jumping tobuffersize + 1 tasks in buffer
  • yield already available result without needing to wait, going back tobuffersize tasks in buffer
• at# point B there is stillbuffersize buffered tasks
• 2nd call tonext: same

pros:

• buffersize tasks in buffer between two calls tonext
• jumps tobuffersize + 1 during a call tonext but is back instantly tobuffersize because the next result is already available when we enqueued the next task (the closest we can get to a yield-and-enqueue-at-the-same-time).

Let me know if it makes sense 🙏🏻