summaryrefslogtreecommitdiffstats
path: root/Objects/object.c
diff options
context:
space:
mode:
authorAmaury Forgeot d'Arc <amauryfa@gmail.com>2007-11-15 20:52:21 (GMT)
committerAmaury Forgeot d'Arc <amauryfa@gmail.com>2007-11-15 20:52:21 (GMT)
commitb7f17e4bb4627a0a8bd9a4fe20e9f4e26e9a4d28 (patch)
tree5c38ca1612fe95bee26dce5af472585b33fd0a74 /Objects/object.c
parent519a042c7c248e3ae23cf2a3c1152f91a5bd2791 (diff)
downloadcpython-b7f17e4bb4627a0a8bd9a4fe20e9f4e26e9a4d28.zip
cpython-b7f17e4bb4627a0a8bd9a4fe20e9f4e26e9a4d28.tar.gz
cpython-b7f17e4bb4627a0a8bd9a4fe20e9f4e26e9a4d28.tar.bz2
Found another memory leak in longrangeiter. And redo the previous correction
without calling PyType_Ready(). Question 1: Should the interpreter register all types with PyType_Ready()? Many types seem to avoid it. Question 2: To reproduce the problem, run the following code: def f(): while True: for a in iter(range(0,1,10**20)): pass f() And watch the memory used by the process. How do we test this in a unittest?
Diffstat (limited to 'Objects/object.c')
-rw-r--r--Objects/object.c3
1 files changed, 0 insertions, 3 deletions
diff --git a/Objects/object.c b/Objects/object.c
index fa5eb4d..df93a19 100644
--- a/Objects/object.c
+++ b/Objects/object.c
@@ -1509,9 +1509,6 @@ _Py_ReadyTypes(void)
if (PyType_Ready(&PyStdPrinter_Type) < 0)
Py_FatalError("Can't initialize StdPrinter");
-
- if (PyType_Ready(&PyRange_Type) < 0)
- Py_FatalError("Can't initialize 'range'");
}