Message385067
| Author | dlukes |
|---|---|
| Recipients | Klamann, bquinlan, dlukes, ezio.melotti, josh.r, max |
| Date | 2021-01-14.11:06:39 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1610622399.29.0.495500140745.issue29842@roundup.psfhosted.org> |
| In-reply-to |
| Content | |
|---|---|
Any updates on this? Making Executor.map lazier would indeed be more consistent and very useful, it would be a shame if the PR went to waste :) It's a feature I keep wishing for in comparison with the older and process-only multiprocessing API. And eventually, yielding results in the order that tasks complete, like multiprocessing.Pool.imap_unordered, could be added on top of this, which would be really neat. (I know there's concurrent.futures.as_completed, but again, that one doesn't handle infinite iterables.) |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2021-01-14 11:06:39 | dlukes | set | recipients: + dlukes, bquinlan, ezio.melotti, max, josh.r, Klamann |
| 2021-01-14 11:06:39 | dlukes | set | messageid: <1610622399.29.0.495500140745.issue29842@roundup.psfhosted.org> |
| 2021-01-14 11:06:39 | dlukes | link | issue29842 messages |
| 2021-01-14 11:06:39 | dlukes | create | |