Estoy en Windows con Python 2.5. Tengo un archivo abierto para escribir. Escribo algunos datos. Cierre el archivo de llamada. Cuando trato de eliminar el archivo de la carpeta usando el Explorador de Windows, se produce un error, diciendo que un proceso aún tiene un control para el archivo.¿Por qué Python no libera los identificadores de archivos después de llamar a file.close()?
Si apago Python, y lo intento de nuevo, tiene éxito.
Lo cierra. ¿Seguro que se llama a f.close()? Acabo de probar el mismo escenario y Windows borra el archivo para mí.
¿Está manejando alguna excepción alrededor del objeto de archivo? Si es así, asegúrese de que el control de errores es como la siguiente:
f = open("hello.txt")
try:
for line in f:
print line
finally:
f.close()
Al considerar por qué usted debe hacer esto, considere las siguientes líneas de código:
f = open('hello.txt')
try:
perform_an_operation_that_causes_f_to_raise_an_exception()
f.close()
except IOError:
pass
Como se puede ver, f.close nunca se llamará en el código anterior. El problema es que el código anterior también provocará que f no obtenga la basura recolectada. La razón es que todavía se hará referencia a f en sys.traceback, en cuyo caso la única solución es llamar manualmente close f en un bloque finally o establecer sys.traceback en None (y recomiendo fuertemente el primero).
explicado en el tutorial:
with open('/tmp/workfile', 'r') as f:
read_data = f.read()
funciona Al escribir o decapado/desestibado, también
En realidad no es necesario que intente bloque finally: camino de Java de hacer las cosas, no Python
Definitivamente desea tener el bloque 'finally' si el código anterior tiene una posibilidad de lanzar una excepción, que cualquier operación de archivo tiene el potencial de hacer. – Davy8
Davy: desde python 2.5 en adelante, el objeto de archivo ha sido equipado con los métodos '_enter_' y' _exit_'. Python evalúa la expresión, llama al método '_enter_', luego ejecuta el cuerpo del código y, pase lo que pase en ese código, llama al método' _exit_' del objeto guard. Se ocupa de las excepciones y siempre cierra el archivo. Con sustitutos try-finally. Tienes que habilitarlo: 'desde __future__ import with_statement –
Estaba buscando esto, porque me pasó lo mismo. La pregunta no me ayudó, pero creo que descubrí lo que sucedió.
En la versión original del script que escribí, no agregué una cláusula 'finally' al archivo en caso de una excepción.
Estaba probando el script desde el prompt interactivo y obtuve una excepción mientras el archivo estaba abierto. Lo que no me di cuenta fue que el objeto de archivo no se recolectó de inmediato. Después de eso, cuando ejecuté el script (todavía de la misma sesión interactiva), aunque se estaban cerrando los nuevos objetos del archivo, el primero aún no lo había sido, y por lo tanto el manejador del archivo aún estaba en uso, desde el perspectiva del sistema operativo.
Una vez que cerré la solicitud interactiva, el problema desapareció, recordando que se produjo una excepción mientras el archivo estaba abierto y me di cuenta de lo que estaba sucediendo. (Moraleja: No intente programar en el sueño insuficiente.))
Naturalmente, no tengo idea si esto es lo que sucedió en el caso del póster original, e incluso si el cartel original todavía está presente, Puede que no recuerde las circunstancias específicas, pero los síntomas son similares, así que pensé en agregar esto como algo para verificar, para cualquier persona atrapada en la misma situación y buscando una respuesta.
Nunca he conocido a Pythons para lanzar * cualquier cosa * fácilmente, deja a lo largo de pequeños archivos pobres. : P: P – Cerebrus
@Cerberus Tee hee! – Pitarou
Intente publicar el programa completo más pequeño que pueda hacer que muestre el error. Esto no debería estar pasando así que probablemente sea algo simple de solucionar. – dwc