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

[Andrae Muys]

rurpy at yahoo.com wrote:
> Thank you for the posting Andrae, it has increased my
> knowledge.
No problem, happy to help.
> But my original point was there are cases (often involving
> file iterators) where the problem's complexity seems to be
> on the same order as problems involving iterate-to-shortest
> solutions, but, while the latter have simple, one function
> call solutions, solutions for the former are far more complex
> (as your post illustrates).  This seems at best unbalanced.
> When encountered by someone with less than your level of
> expertise, it leads to the feeling, "jeez, why is this simple
> problem take hours to figure out and a half dozen function
> calls?!?"

I agree, having had to think about how to implement padding with
truncating api to implement your use-case, padding is a useful feature
to have available.  I didn't mean to imply otherwise.  You asked why
truncating is a common choice in the design of izip-like functions
(Python, ML, Haskell, Scheme); my post was an attempt to answer that.
The summary of my post is:

1. Either can be implemented in terms of the other.
2. Using a truncating zip instead of a padding zip leads to an
incorrect result.
3. Using a padding zip instead of a truncating zip leads to
non-termination.
4. A terminating bug is preferred to a non-terminating bug.

Hence zip is generally truncating.

Andrae Muys