Creo que esta pregunta es más un "estilo de codificación" que un problema técnico.python cerrar el descriptor del archivo pregunta
dijo que tengo una línea de código:
buf = open('test.txt','r').readlines()
...
¿El descriptor de archivo se cierran automáticamente, o va a permanecer en la memoria? Si el descriptor de archivo no está cerrado, ¿cuál es la forma preferida de cerrarlo?
Si asigna el objeto de archivo a una variable, puede cerrar explícitamente con .close()
f = open('test.txt','r')
buf = f.readlines()
f.close()
alternativa (y más generalmente preferido), puede utilizar el with palabra (Python 2.5 y superior) como se menciona en la Python docs:
es una buena práctica para usar el
withpalabra clave cuando se trata de archivos objetos. Esto tiene la ventaja de que el archivo se cierra correctamente después de que su suite finaliza, incluso si se levanta una excepción en el camino. También es mucho más corta que la escritura equivalentes try-finally bloques:
>>> with open('test.txt','r') as f:
... buf = f.readlines()
>>> f.closed
True
Se mantendrá en la memoria hasta que el recolector de basura la cierre. Siempre debe cerrar explícitamente los descriptores de archivos. Sólo hacer algo como esto:
with open('test.txt', 'r') as f:
buf = f.readlines()
Estrictamente hablando, usar con no es "explícitamente" cerrando el archivo ... –
@Hugh Bothwell: Hmm. Supongo que depende de tu definición de explícitamente. Lo llamaría cerrarlo explícitamente. – Falmarri
Es más explícito en cuanto a que ahora sabemos exactamente cuándo se cerrará el archivo, pero no es realmente lo que llamaría explícito en el sentido de programación. –
lo general, en CPython, el archivo se cierra de inmediato cuando el recuento de referencias llega a cero (aunque este comportamiento no está garantizada para el futuro versiones de CPython)
En otras implementaciones, como Jython, el archivo no se cerrará hasta que se recoja el garbarge, lo que puede pasar mucho tiempo después.
Es un estilo pobre tener un código que funcione de manera diferente según el comportamiento de la implementación.
Si es sólo para un script polvo rápido o algo que se está tratando en el intérprete de concha es lo suficientemente bueno, pero para cualquier tipo de trabajo de producción por lo general debe utilizar un gestor de contexto como en la respuesta de Falmarri
+1 Buenos puntos prácticos. – martineau
Un ejemplo de este bitting del codificador en diferentes implementaciones de Python fue que Mercurial agotaría la cantidad de archivos abiertos permitidos por el sistema operativo cuando se ejecuta en PyPy. Mercurial está experimentando cambios para solucionar esto. – TryPyPy
Será automáticamente cerrado, pero depende de la implementación exactamente cuándo. Es más agradable usar explícitamente un bloque con, pero si solo estás escribiendo un pequeño script para ti que ejecutas ocasionalmente, en realidad no importa.
El tamaño del script y la frecuencia de ejecución son sublimemente irrelevantes. Si el script itera sobre muchos archivos abriéndolos, realmente importa si no los está cerrando. Tarde o temprano se quedará sin controladores y se bloqueará. –
Tienes razón, me perdí de escribir la parte importante: que era para él y de vez en cuando. Porque entonces, cuando se quede sin identificadores de archivos, se dará cuenta. ;) Pero si lo pone en el sitio de un cliente. : - / –
"buf" en este caso será una lista - no hay un método "cerrado" en él. – jsbueno
'with' está disponible en 2.5, pero debe importarlo usando' from __future__ import with_statement'. Esto no es necesario desde 2.6 en adelante. –
@jsbueno gracias por captar mi error!¡Actualicé la respuesta para reflejar su observación! @Jay Conrod, gracias por la información! (Salté de 2.4 a 2.7, ¡así que nunca experimenté eso!) – sahhhm