[issue19993] Pool.imap doesn't work as advertised

Josh Rosenberg added the comment: Related: issue29842 "Make Executor.map work with infinite/large inputs correctly" for a similar problem in concurrent.futures (but worse, since it doesn't even allow you to begin consuming results until all inputs are

[issue19993] Pool.imap doesn't work as advertised

Change by Ned Deily : -- nosy: +davin, pitrou ___ Python tracker ___ ___ Python-bugs-list

[issue19993] Pool.imap doesn't work as advertised

Alex Garel added the comment: Hello, I think this is a really important feature, it hits me hard those days. It would also solve https://bugs.python.org/issue19173 in a nice way. -- nosy: +alex-garel ___ Python tracker

[issue19993] Pool.imap doesn't work as advertised

New submission from Jurjen N.E. Bos: The pool.imap and pool.imap_unordered functions are documented as a lazy version of Pool.map. In fact, they aren't: they consume the iterator argument as a whole. This is almost certainly not what the user wants: it uses unnecessary memory and will be

[issue19993] Pool.imap doesn't work as advertised

Tim Peters added the comment: Nice to see you, Jurjen! Been a long time :-) I'd like to see changes here too. It's unclear what a lazy version is intended to mean, exactly, but I agree the actual behavior is surprising, and that mpool.py is a lot less surprising in several ways. I got

[issue19993] Pool.imap doesn't work as advertised

Tim Peters added the comment: Just for interest, I'll attach the worm-around I mentioned (imu.py). At this level it's a very simple implementation, but now that I look at it, it's actually a lazy implementation of imap() (or of an unimaginative ;-) imap_unordered()). -- Added file: