del MyClass no llama al objeto .__ del __()

Question

Tengo una clase que abre un archivo para escribir. En mi destructor, llamo a la función que cierra el archivo:

class MyClass: 
    def __del__(self): 
     self.close() 

    def close(self): 
     if self.__fileHandle__ is not None: 
       self.__fileHandle__.close() 

pero cuando se borra el objeto con un código como:

myobj = MyClass() 
myobj.open() 
del myobj 

si trato de reinstantiate el objeto, me sale un error de valor :

ValueError: The file 'filename' is already opened. Please close it before reopening in write mode. 

mientras que si llamo myobj.close() antes del myobj no entiendo este problema. Entonces, ¿por qué no se llama a __del__()?

Answer 1

¿Estás seguro de que deseas utilizar __del__? Hay issues con __del__ y recolección de basura.

Se podría hacer MiClase un context manager lugar:

class MyClass(object): 
    def __enter__(self): 
     return self 
    def __exit__(self,ext_type,exc_value,traceback): 
     if self.__fileHandle__ is not None: 
       self.__fileHandle__.close() 

De esta manera, se puede usar MyClass así:

with MyClass() as myobj: 
    ... 

y myobj.__exit__ (y por lo tanto self.__fileHandle__.close()) será llamada cuando las hojas de Python el with-block.

Answer 2

Eso no es lo que del hace. Es desafortunado que __del__ tenga el mismo nombre que del, porque no están relacionados entre sí. En terminología moderna, el método __del__ se llamaría finalizador, no destructor y la diferencia es importante.

La corta diferencia es que es fácil de garantizar un destructor cuando se llama, pero hay muy pocas garantías sobre cuándo __del__ serán llamados y podría no ser llamado. Hay muchas circunstancias diferentes que pueden causar esto.

Si desea un alcance léxico, use una declaración with. De lo contrario, llame directamente al myobj.close(). La instrucción del solo elimina referencias, no objetos.

Encontré otra respuesta (link) a una pregunta diferente que responde a esto con más detalle. Es desafortunado que la respuesta aceptada a esa pregunta contenga errores atroces.

Editar: Como notaron los comentaristas, debe heredar de object. Eso está bien, pero aún es posible que __del__ nunca sea llamado (podría tener suerte). Vea la respuesta vinculada arriba.

Answer 3

Su código debe heredar de object - no hacerlo se ha considerado obsoleto (excepto en casos especiales) durante al menos seis años.

se puede leer acerca __del__ aquí: http://docs.python.org/reference/datamodel.html#object.del

La versión corta de por qué tiene que heredar de object es que __del__ sólo es "mágica" en las clases de nuevo estilo.

Si necesita confiar en las llamadas de un finalizador, le sugiero encarecidamente que utilice el enfoque de gestor de contexto recomendado en otras respuestas, porque esa es una solución portátil y sólida.

Answer 4

Quizás algo más se está refiriendo a él, razón por la cual __del__ no se está llamando (todavía).

consideran este código:

#!/usr/bin/env python 

import time 

class NiceClass(): 
    def __init__(self, num): 
     print "Make %i" % num 
     self.num = num 
    def __del__(self): 
     print "Unmake %i" % self.num 

x = NiceClass(1) 
y = NiceClass(2) 
z = NiceClass(3) 
lst = [x, y, z] 
time.sleep(1) 
del x 
del y 
del z 
time.sleep(1) 
print "Deleting the list." 
del lst 
time.sleep(1) 

No llama __del__ de NiceClass casos, hasta que eliminemos la lista que hace referencia a ellos.

A diferencia de C++, __del__ no se llama incondicionalmente para destruir el objeto bajo demanda. GC hace las cosas un poco más difíciles. Aquí hay alguna información: http://arctrix.com/nas/python/gc/