Message69758
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. |
|
Date |
User |
Action |
Args |
2008-07-16 04:01:53 | esrever_otua | set | spambayes_score: 0.00356017 -> 0.0035601726 recipients:
+ esrever_otua |
2008-07-16 04:01:53 | esrever_otua | set | spambayes_score: 0.00356017 -> 0.00356017 messageid: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za> |
2008-07-16 04:01:52 | esrever_otua | link | issue3373 messages |
2008-07-16 04:01:51 | esrever_otua | create | |
|