Software bugs aren't inevitable

[Steven D'Aprano]

On Thu, 15 Sep 2005 11:38:57 +0200, Jerzy Karczmarczuk wrote:

>> Yes, the maximum recursion depth in Python is an artificial limit. But
>> that artificial limit is built into Python specifically to protect you
>> from running into a real recursion limit based on the hardware and
>> architecture of your PC, with painful consequences.
> 
> Oh, I LOVE technical solutions like that:
> 
>     "Everybody knows that you should not exceed some speed in your car.
>      So, our new technology is such that if you reach 160 km per hour,
>      your engine breaks.
>      Surely it is an artificial limit, but it is there to protect you from
>      worse problems with painful consequences."

Yes, in an ideal world, there would be some way for Python to magically
work out what the rest of the recursion would have calculated without
actually needing to calculate it recursively. Maybe all the fans of
Functional Programming will suggest patches to Python that will optimize
recursion so there will be no need for the maximum recursion depth
exception. But until then, it is better to explicitly fail than to return
an incorrect answer.

Either way, unless somebody redoes the Python language, it is a limit we
are stuck with in the real world of Python programming.

> I do not feel guilty for proposing a function which fails for n>1000.

That's a curious attitude to have. I always feel guilty when I write a
program that fails for some legitimate input.


> I am sorry, but Python, as every other programming language is full of
> decisions ad hoc, not always universally appreciated. Recursion can be
> and IS often optimised, and tail recursion in functional languages is
> entirely removed (no stack filling.) Stacks can be and are sometimes
> allocated on heap, so the comment of somebody who discussed the
> dichotomy stack/heap, pointing out the difference in size, may be
> altogether irrelevant. Again, we, the users are not responsible for the
> memory allocation policy in Python...

But that is precisely my point. Ideas that work well in theory can fail
badly when put into practice because of limitations of the language used.
Algorithms that work poorly in one language can work wonderfully in
another.


> On the other hand, I suspect that there will be people who
> will not follow this thread, who will just remember your first posting
> on the subject, and they will remain convinced that recursion /per se/
> is lousy, and that your cascading algorithm is *THE* standard recursive
> solution. Yes, YOU are in the state of sin! [Optional smiley here].

Yes, good point. In hindsight, I should have reworded my post to be more
clear. I am not opposed to recursion itself, just overly broad advice that
recursion is always good and modifying variables is always bad.

[snip]
> And here the recursion limit won't get you!! But the memoization
> techniques are rarely taught nowadays...

Which is a pity, because they are a powerful technique.


-- 
Steven.