homepage

I'm not sure this is bug or not, but shouldn't `io' be collected by
refcount GC? This happens on python2.5 but doesn't happend on python3.0.
import os
def foo():
 io = open("a.txt", "w")
 raise RuntimeError()
try:
 foo()
except:
 pass
os.remove("a.txt") # WindowsError (Error32)
 # Process cannot access to the file.
 # Another process is using it.

The interpreter holds onto sys.exc_traceback even after the except
block. This refers to the frame, which refers to the file object.

Hmm, when exception occurs in some frame, its reference will be
retained even after exiting function? Indeed, extra
exception fixed problem.
import os
def foo():
 io = open("a.txt", "w")
 raise RuntimeError()
try:
 foo()
except:
 pass
try:
 raise RuntimeError()
except:
 pass
os.remove("a.txt") # fine
But still I'm little confused why this code prints "del".
class A:
 def __del__(self):
 print "del"
def foo():
 a = A()
 raise RuntimeError()
try:
 foo()
except:
 pass
I found this behavior when investigating issue3210. When
Lib/subprocess.py (814)'s CreateProcess() raises exception,
p2cread will be freed by refcount GC, it never happen before
os.remove(). And this error is also fixed by same hack.
import subprocess, os
file = open("filename", "w")
try:
 proc = subprocess.Popen("nosuchprogram", stdout=file)
except OSError:
 pass
try:
 raise RuntimeError() # hack
except:
 pass
file.close()
os.remove("filename")

>But still I'm little confused why this code prints "del".
Oh, sorry, kick me. "del" should be printed when interpreter exits. :-)

> Hmm, when exception occurs in some frame, its reference will be
> retained even after exiting function?
Correct. When a traceback is produced, all frames get linked, be
able to print later the traceback with source code information.
Each frame keeps all its local variables.

I understand. Thank you.

You don't need to raise another exception, calling sys.exc_clear()
should be fine. But a cleaner way to write your example is:
def foo():
 with open("a.txt", "w") as io:
 raise RuntimeError()
"with" will automatically close the file when the block exits.
If you are concerned with Python < 2.5 compatibility, use "try: ...
finally:" instead.
And, you're right, the problem doesn't occur at all in Python 3.0
because the exception is cleaned up after the end of the "except:" block
catching it.