[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