[David Murmann] > i'd like izip > to change, too. The zip() function, introduced in Py2.0, was popular and broadly useful. The izip() function is a zip() substitute with better memory utilization yet almost identical in how it is used. It is bugfree, successful, fast, and won't change.
The map() function, introduced shortly after the transistor was invented, incorporates an option that functions like zip() but fills-in missing values and won't truncate. It probably seemed like a good idea at the time, but AFAICT no one uses it (Alex once as a newbie; Strakt once; me never; the standard library never; etc). So, the question is not whether non-truncating fill-in will be available. Afterall, we've already got one: map(None, it1, it2). Instead, the question is whether to introduce another substantially identical function with improved memory utilization and a specifiable fill-in value. But, why would you offer a slightly improved variant of something that doesn't get used? Put another way: If you don't use map(None, it1, it2), then you're going to have a hard time explaining why you need itertools.izip_longest(it1, it2). > second (and i think this is the reason for the use-case search) > is that someone has to do it. that means implement it and fix > the docs, add a test-case and such stuff. if there are not many > use-cases the effort to do so might not be worthwhile. In this case, the coding and testing are easy. So that's not the problem. The real issue is the clutter factor from introducing new functions if they're not going to be used, if they don't have good use cases, and if there are better ways to approach most problems. The reason for the use case search is to determine whether izip_longest() would end-up as unutilized cruft and add dead-weight to the language. The jury is still out but it doesn't look promising. Raymond -- http://mail.python.org/mailman/listinfo/python-list
