RetroSearch Browse

Tue Mar 2 12:26:56 EST 2004 · http://mail.python.org/pipermail/python-dev/2004-March/042885.html

Jeremy Hylton <jeremy at alum.mit.edu> writes:

> On Tue, 2004-03-02 at 12:17, Bob Ippolito wrote:
>> Well it's already true to some small extent because of the recursion 
>> depth limit.  Though, this has only been a problem for me once, and I 
>> rewrote it as a large ugly iterative version.
>
> Don't know the particulars, but I thought it worth mentioning that the
> recursion limit is set fairly conservatively.  In many cases, it's
> possible to boost the recursion limit.  I don't know if it's ever
> practical, because if something goes wrong you get a segfault.
>
> Different kinds of recursive Python calls generated different numbers of
> C stack frames.  So if you have a recursive __repr__(), it will consume
> more C stack than a simple Python function.
>
> Python's recursion limit is set to 1000 in 2.3.  On my box (RH9) the
> first crash I get is with a recursion limit of 5800.  It blows up on the
> repr case.  For simple recursive functions, I can push it all the way up
> to 21,500.

But list_sort pushes quite a large object onto the stack.  So if you
arrange for that too appear on the stack repeatedly, you get a crash
much earlier.

Python's recursion limit is a nasty hack.  Unfortunately, all the
alternatives are worse :-( (except some variant of stackless, I guess,
but that probably doesn't help the list_sort business).

Cheers,
mwh

-- 
  I have a cat, so I know that when she digs her very sharp claws into
  my chest or stomach it's really a sign of affection, but I don't see
  any reason for programming languages to show affection with pain.
                                        -- Erik Naggum, comp.lang.lisp

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2004-March/042885.html below:

[Python-Dev] [ python-Patches-876206 ] scary frame speed hacks