Real-world use cases for map's None fill-in feature?
andrae.muys at gmail.com
Tue Jan 24 20:32:38 EST 2006
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
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 :).
More information about the Python-list