[Python-checkins] cpython (merge 3.3 -> default): Merge from 3.3
nick.coghlan
python-checkins at python.org
Mon Nov 5 11:41:08 CET 2012
http://hg.python.org/cpython/rev/c4b5dfcb4a01
changeset: 80267:c4b5dfcb4a01
parent: 80265:48228fb874c1
parent: 80266:e29b50e1e8e5
user: Nick Coghlan <ncoghlan at gmail.com>
date: Mon Nov 05 20:40:57 2012 +1000
summary:
Merge from 3.3
files:
Lib/test/crashers/recursion_limit_too_high.py | 16 ----------
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/Lib/test/crashers/recursion_limit_too_high.py b/Lib/test/crashers/recursion_limit_too_high.py
deleted file mode 100644
--- a/Lib/test/crashers/recursion_limit_too_high.py
+++ /dev/null
@@ -1,16 +0,0 @@
-# The following example may crash or not depending on the platform.
-# E.g. on 32-bit Intel Linux in a "standard" configuration it seems to
-# crash on Python 2.5 (but not 2.4 nor 2.3). On Windows the import
-# eventually fails to find the module, possibly because we run out of
-# file handles.
-
-# The point of this example is to show that sys.setrecursionlimit() is a
-# hack, and not a robust solution. This example simply exercises a path
-# where it takes many C-level recursions, consuming a lot of stack
-# space, for each Python-level recursion. So 1000 times this amount of
-# stack space may be too much for standard platforms already.
-
-import sys
-if 'recursion_limit_too_high' in sys.modules:
- del sys.modules['recursion_limit_too_high']
-import recursion_limit_too_high
--
Repository URL: http://hg.python.org/cpython
More information about the Python-checkins
mailing list