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

[Andrae Muys]

rurpy at yahoo.com wrote:
> > 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).

This is not a paradigm based preference.  It derives from the basic
fact that you can test for an incorrect result, but you can't test for
non-termination.  Therefore if you have to choose between making it
easy to inadvertantly introduce either non-termination or a trivial
logic error, you are better off chosing the trivial logic error.  That
preference is independent of which
structured/object/functional/logic/constraint/concurrent/reactive
school of programming you adhere to.

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

Two problems with that.  One we are dealing with a bug, not an error.
Two, even if we classified the bug as an error noticing non-termination
requires solving the halting-problem whereas noticing an erroneous
result simply requires a unit-test.

The reason why you see this in FP and not in OOP is that
infinite/unbounded/v.large values are trivial to define in FP and
(generally) not in OOP.  Consequently the potential for inadvertant
non-termination simply doesn't arise in OOP.

> > 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.

Of course not --- only by making python non-turing complete could such
a thing be achieved. But you have overstated the position. This isn't a
matter of outlawing function that could be used to write a
non-terminating prodcedure.  It's about a simple API design decision.
A choice between two options.  It doesn't require the designer to
decide that one is *right* and one *wrong*.  Just that one is at least
slightly better than the other; or even that one was chosen simply
because either was better than neither.  API design decisions are not
personal vendettas against your use-case :).

Andrae Muys