On Apr 28, 2010, at 8:59 AM, Mathias Panzenböck wrote:
See:
map(None,['a','b'],[]) [('a', None), ('b', None)] list(imap(None,['a','b'],[])) []
Why is that?
Excerpt from the source file at http://svn.python.org/view/python/trunk/Modules/itertoolsmodule.c?view=marku... : /* imap() is an iterator version of __builtins__.map() except that it does not have the None fill-in feature. That was intentionally left out for the following reasons: 1) Itertools are designed to be easily combined and chained together. Having all tools stop with the shortest input is a unifying principle that makes it easier to combine finite iterators (supplying data) with infinite iterators like count() and repeat() (for supplying sequential or constant arguments to a function). 2) In typical use cases for combining itertools, having one finite data supplier run out before another is likely to be an error condition which should not pass silently by automatically supplying None. 3) The use cases for automatic None fill-in are rare -- not many functions do something useful when a parameter suddenly switches type and becomes None. 4) If a need does arise, it can be met by __builtins__.map() or by writing: chain(iterable, repeat(None)). 5) Similar toolsets in Haskell and SML do not have automatic None fill-in. */
I propose that imap should work like map (except from being a generator, of course).
Sorry, this was considered and rejected a long time ago. Changing the none fill-in behavior would break working code. FWIW, izip_longest() supports fill-in behavior for the handful of use cases that need it. Raymond