{"id":1141,"date":"2012-10-24T17:05:16","date_gmt":"2012-10-24T16:05:16","guid":{"rendered":"http:\/\/www.stenyak.com\/?p=1141"},"modified":"2012-10-24T17:05:16","modified_gmt":"2012-10-24T16:05:16","slug":"liberacion-de-recursos-en-python","status":"publish","type":"post","link":"https:\/\/www.stenyak.com\/?p=1141","title":{"rendered":"Liberaci\u00f3n de recursos en python"},"content":{"rendered":"
Pong\u00e1monos en contexto: estamos usando Python, un lenguaje no mucho m\u00e1s viejo que Java, y donde una de las primeras lecciones que se aprenden es que la memoria es gestionada autom\u00e1ticamente.<\/div>\n
\n

Hurrah! Ya no hay que hacer malloc<\/code>s, ni delete<\/code>s, ni tener destructores, ni hostias en vinagre, \u00a0porque python lo hace todo!<\/p>\n

 <\/p>\n<\/div>\n

\u00bfEntonces, por qu\u00e9 nos topamos a menudo con c\u00f3digo como \u00e9ste?:<\/div>\n
\n
f = open(\"foo.txt\", \"r\")\ntext = f.readlines()\nf.close<\/strong>()        # WAT.<\/pre>\n<\/blockquote>\n
O bien esto?:<\/div>\n
\n
with<\/strong> open(\"foo.txt\", \"r\") as f: # WAT.\n    text = f.readlines()<\/pre>\n<\/blockquote>\n
\n
Y no hablo solo de ficheros, sino cualquier tipo de recurso: conexiones de red, puertos hardware, primitivas de sincronizaci\u00f3n, memor\u00eda RAM, etc.<\/p>\n
(nota: el texto a continuaci\u00f3n es b\u00e1sicamente un copiapega de un mail \u00a0enviado a una lista de correo privada. lo digo por si algo no encajara…)<\/em><\/span><\/p>\n
Vamos a meternos en detalles (al menos hasta donde yo conozco; y no dudeis en corregirme si veis alg\u00fan fallo, as\u00ed aprendemos todos):<\/p>\n<\/div>\n
No es necesario hacer un close:<\/h2>\n
\n
Es cierto, no es estrictamente necesario<\/strong> hacer un close<\/code>, porque por defecto el lenguaje python se encarga de esas tareas mundanas por nosotros.\u00a0El problema es que lo hace autom\u00e1ticamente<\/strong>, y a su manera<\/strong>, y puede que no<\/strong> sea la que nos interese.<\/p>\n
De ah\u00ed que se suela hacer un close()<\/code> expl\u00edcito (ya sea con una llamada directa, o mediante el “with<\/code>” que he comentado antes).<\/p>\n
\u00bfPor qu\u00e9 podr\u00eda no interesarnos lo que hace python por defecto?
\nPuede ser por muchos motivos:<\/p>\n<\/div>\n
La vida de las variables en python es un detalle de implementaci\u00f3n:<\/h2>\n
\n
Por ejemplo, el int\u00e9rprete que solemos usar (CPython<\/a>) mantiene los objetos en memoria como m\u00ednimo hasta que salen de \u00e1mbito<\/strong>, y como m\u00e1ximo hasta cuando el<\/strong> GC<\/strong><\/em> de CPython lo determina<\/strong> en alguna de sus pasadas (cuando existen ciclos de referencias, y seg\u00fan el perfil de uso de memoria de nuestro programa).<\/p>\n
En cristiano<\/strong>: que una variable que se sale de \u00e1mbito, podr\u00eda eliminarse al momento, o podr\u00eda tardar media hora<\/strong> en ser eliminada por el GC. Imaginad que las conexiones a una misma c\u00e1mara IP solo se cierran cada diez minutos (porque hemos delegado todo al GC), y que esa c\u00e1mara acepta como m\u00e1ximo 4 conexiones simult\u00e1neas…<\/p>\n
(otras implementaciones como PyPy<\/a>, Jython<\/a>, IronPython<\/a>, etc. pueden<\/em> comportarse distinto)<\/p>\n
En .NET ocurre lo mismo, como bien dice David (de ah\u00ed viene el jaleo de usar iDisposable<\/code>s incluso para recursos managed…), y en Java m\u00e1s de lo mismo.<\/p>\n<\/div>\n
Bugs de terceras partes:<\/h2>\n
\n
Alguna vez hemos sufrido bugs de conteo de referencias<\/strong>, por alguna librer\u00eda de python escrita en C que no actualizaba correctamente los conteos y provocaba leaks de nuestros propios objetos.<\/p>\n
Si esos objetos tenian recursos abiertos, hay que cerrarlos a mano<\/strong>, o sino seguir\u00e1n abiertos hasta que muera nuestro proceso de python.<\/p>\n<\/div>\n
Bugs propios:<\/h2>\n
\n
Incluso asumiendo<\/strong> una gesti\u00f3n de memoria perfecta<\/em> e instant\u00e1nea<\/em> por parte de CPython (que no<\/strong> es el caso necesariamente, como he explicado), existen casos en que nuestro c\u00f3digo puede estar manteniendo variables en memoria (y con recursos abiertos) sin que nos demos cuenta.<\/p>\n
Algunos casos t\u00edpicos:<\/p>\n<\/div>\n
Variables de instancia:<\/h4>\n
\n
def __init__(self):\n\u00a0 \u00a0 self.my_file<\/strong> = open(...)\n\u00a0 \u00a0 print self.my_file.readline()\n\u00a0 \u00a0 # el recurso permanecer\u00e1 abierto al menos\n    # hasta que el objeto self<\/strong> sea eliminado<\/pre>\n<\/blockquote>\n
Variables dentro de una funci\u00f3n de larga duraci\u00f3n:<\/h4>\n
\n
my_file<\/strong> = open(...);\nprint my_file.readline()\nwhile True:\n\u00a0 \u00a0 # bucle principal del programa\n\u00a0 \u00a0 # my_file sigue con el recurso abierto al\n    # menos hasta el fin de la funci\u00f3n<\/strong><\/pre>\n<\/blockquote>\n
Variables que por su naturaleza son compartidas:<\/h4>\n
El ejemplo m\u00e1s claro, un mutex<\/code>. Tambi\u00e9n sem\u00e1foros, bufferes de memoria compartidos por varios hilos, etc.<\/div>\n
Variables referenciadas por closures:<\/h4>\n
Aunque salgamos de una funci\u00f3n, los closures alargan la vida de las variables que cogen prestadas de su funci\u00f3n padre:<\/div>\n
\n
def my_function():\n\u00a0 \u00a0 my_file<\/strong> = open(\"foobar\")\n\u00a0 \u00a0 def internal_function():\n\u00a0 \u00a0 \u00a0 \u00a0 return my_file.readline()\n\u00a0 \u00a0 return internal_function\nmy_closure = my_function()\n# my_file<\/strong> sigue existiendo y con el archivo\n# abierto, hasta que se destruya my_closure<\/strong><\/pre>\n<\/blockquote>\n
\u00c1mbito de funci\u00f3n, no de bloque:<\/h4>\n
Es algo b\u00e1sico de python, pero no est\u00e1 mal repasarlo: en python no<\/strong> vale definir<\/em>\u00a0una variable dentro de un bloque<\/strong> (por ej. dentro de un for<\/code>), porque su \u00e1mbito es siempre\u00a0de funci\u00f3n<\/strong>:<\/div>\n
\n
for path<\/strong> in [\"\/a.txt\", \"b.txt\"]:\n\u00a0 \u00a0 my_file<\/strong> = fopen(path...)\n\u00a0 \u00a0 print my_file.readline()\nprint path<\/strong> \u00a0 \u00a0# va a imprimir \"b.txt\", aunque\n              # estemos fuera del bucle.\nprint my_file<\/strong> # lo mismo pasa con my_file, aunque\n              # pueda ser anti-intuitivo\ndel<\/strong> my_file \u00a0 # si queremos que se elimine esta\n              # referencia a la variable, y el GC\n              # pueda hacer su trabajo en alg\u00fan<\/strong>\n              # momento indeterminado<\/strong><\/pre>\n
while True:\n\u00a0 \u00a0 #bucle principal de duraci\u00f3n infinita<\/pre>\n<\/blockquote>\n
<\/div>\n
Bueno, creo que as\u00ed queda una explicaci\u00f3n m\u00e1s completa (y espero que tambi\u00e9n sea t\u00e9cnicamente correcta!) \ud83d\ude42<\/div>\n","protected":false},"excerpt":{"rendered":"
Pong\u00e1monos en contexto: estamos usando Python, un lenguaje no mucho m\u00e1s viejo que Java, y donde una de las primeras lecciones que se aprenden es que la memoria es gestionada autom\u00e1ticamente. Hurrah! Ya no hay que hacer mallocs, ni deletes, ni tener destructores, ni hostias en vinagre, \u00a0porque python lo hace todo!   \u00bfEntonces, por […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[4],"tags":[13],"_links":{"self":[{"href":"https:\/\/www.stenyak.com\/index.php?rest_route=\/wp\/v2\/posts\/1141"}],"collection":[{"href":"https:\/\/www.stenyak.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.stenyak.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.stenyak.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.stenyak.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1141"}],"version-history":[{"count":0,"href":"https:\/\/www.stenyak.com\/index.php?rest_route=\/wp\/v2\/posts\/1141\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.stenyak.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1141"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.stenyak.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1141"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.stenyak.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1141"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}