why has itertools.imap other semantics as the bultin map?
See:
map(None,['a','b'],[]) [('a', None), ('b', None)] list(imap(None,['a','b'],[])) []
Why is that? I propose that imap should work like map (except from being a generator, of course). System Info: Python 2.6.2 (r262:71600, Jan 25 2010, 18:46:47) [GCC 4.4.2 20091222 (Red Hat 4.4.2-20)] on linux2 -panzi
On Wed, Apr 28, 2010 at 5:59 PM, Mathias Panzenböck <grosser.meister.morti@gmx.net> wrote:
See:
map(None,['a','b'],[]) [('a', None), ('b', None)] list(imap(None,['a','b'],[])) []
Why is that? I propose that imap should work like map (except from being a generator, of course).
System Info: Python 2.6.2 (r262:71600, Jan 25 2010, 18:46:47) [GCC 4.4.2 20091222 (Red Hat 4.4.2-20)] on linux2
Practically speaking, Python 2.7 is in beta so even if there was no objection, it's pretty unlikely this lands in 2.x (and 3.x has dropped itertools.imap so there's no confusion). By the way, that's not the only difference of map and itertools.imap:
map(None, 'abc') ['a', 'b', 'c'] list(itertools.imap(None, 'abc')) [('a',), ('b',), ('c',)]
George
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
Raymond Hettinger, 28.04.2010 19:19:
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. */
It's worth adding that itertools.imap() became map() in Python 3. Stefan
participants (4)
-
George Sakkis -
Mathias Panzenböck -
Raymond Hettinger -
Stefan Behnel