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

[rurpy at yahoo.com]

Andrae Muys wrote:
> 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.

(I assume "erroneously" should be inserted in front
of "Using")
OK.

> 4. A terminating bug is preferred to a non-terminating bug.

This is not self-evident to me.  Is this somehow
related to the design philosophy of functional
languages?  I was never aware of such a preference
in conventional procedural languages (though I
could easily be wrong).

It also seems directly counter to Python's "no errors
should pass silently" dogma -- a non termination
seems more noticable than silent erroneous results.

> Hence zip is generally truncating.

I see your point in a theoretical sense, but it still
seems to me be a pretty weak reason for making
a practical decision about what should be in Python,
particularly when the justification is being transfered
from a functional programming domain to an
object/procedural one.  Is any language feature that
might result in non-termination if erroneously used,
to be banned?  That doesn't seem very reasonble.
(I realize you were explaining the rationale behind
the FP choice, not necessarily taking a position
on what should be in Python so the above comment
is directed to the discussion at large.)