Real-world use cases for map's None fill-in feature?

[Raymond Hettinger]

[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