This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author esrever_otua
Recipients esrever_otua
Date 2008-07-16.04:01:51
SpamBayes Score 0.0035601726
Marked as misclassified No
Message-id <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
In-reply-to
Content
The system recursion limit seems to be wildly different in its behaviour
on 2.6/trunk versus, for example, 2.5 or 2.4, EG:

On Python 2.4:
Python 2.4.3 (#1, Dec 11 2006, 11:38:52) 
[GCC 4.1.1 20061130 (Red Hat 4.1.1-43)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class rec(object):
...   child = None
...   def __init__(self, counter):
...     if counter > 0:
...       self.child = rec(counter-1)
... 
>>> mychain = rec(998)
>>>

On Python 2.6/trunk:
Python 2.6b1+ (trunk:64998, Jul 16 2008, 15:50:22) 
[GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class rec(object):
...   child = None
...   def __init__(self, counter):
...     if counter > 0:
...       self.child = rec(counter-1)
... 
>>> mychain = rec(249)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in __init__
[...snip...]
  File "<stdin>", line 5, in __init__
RuntimeError: maximum recursion depth exceeded
>>>

In both cases sys.getrecursionlimit() shows 1000.

Is this behaviour intentional? It looks a lot like a regression of some
sort. It appears to be effectively 4x shorter when creating the nested
object graph.
History
Date User Action Args
2008-07-16 04:01:53esrever_otuasetspambayes_score: 0.00356017 -> 0.0035601726
recipients: + esrever_otua
2008-07-16 04:01:53esrever_otuasetspambayes_score: 0.00356017 -> 0.00356017
messageid: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
2008-07-16 04:01:52esrever_otualinkissue3373 messages
2008-07-16 04:01:51esrever_otuacreate