agregar un campo a object - ex [id de objetos]

[Gabriel Genellina]

En Wed, 30 Apr 2008 23:07:14 -0300, Chema Cortes <py en ch3m4.org> escribió:

> El Thursday 01 May 2008 01:02:27 Milton Galo Patricio Inostroza Aguilera
> escribió:
>> Estimados:
>>
>> * Cada objeto que se cree deberá tener un identificador único dentro
>> del programa
>>

[... respuesta de Chema Cortes con la que estoy totalmente de acuerdo ...]

> Por otro lado, el object.c define la base de las nuevas clases, las que
> unifican tipos y clases. Aún existen las viejas clases, que van por otro
> lado:
>
> class P:
>   pass
>
> issubclass(P,object) --> False

Las clases viejas no *heredan* de object, pero igualmente son *instancias*  
de object como todo objeto en Python.

py> isinstance(P, object)
True

Asi que en principio, para hacer lo que Milton quiere (y no estoy diciendo  
que sea una buena idea...) se le puede agregar un campo nuevo a PyObject  
(en object.h; probablemente en _PyObject_HEAD_EXTRA y  
_PyObject_EXTRA_INIT), modificar _PyObject_New y alrededores, recompilar  
Python, y rogar que todo siga funcionando :)

> No sabría cómo concretar mi ayuda. Aún así se me ocurren un par de cosas:
>
> - considera las listas de igual modo que el paso de variables por  
> referencia,
> no como a objetos normales (eg: similar al Object& de C++)
>
> - guarda siempre una referencia a todo objeto, de este modo podrás seguir
> usando el id() sin riesgo a que se repita (a costa de requerir más  
> memoria).

No sirve porque cambia el comportamiento del programa. Aun cuando uno "no  
deberia" depender de eso, hay mucho codigo que asume que los objetos  
locales desaparecen ni bien se van de ámbito, por poner un ejemplo. O  
aunque sea, que "eventualmente" los objetos se destruyen. Y eso ya no  
pasaría mas.

> Es más, ¿por qué no desactivas totalmente el recolector de basura  
> durante el
> depurado? (gc.disable()). No hace falta que te advierta de la cantidad de
> memoria que vas a necesitar.

Tampoco sirve de mucho. Todos los objetos se destruyen ni bien se libera  
su ultima referencia; el gc sólo busca ciclos de referencias entre objetos  
que no esten referenciados desde fuera del propio ciclo (y entonces  
simplemente libera una de las referencias; eso provoca una liberacion en  
cascada del ciclo completo). Pero no es realmente el gc quien destruye los  
objetos.

py> class X:
...   def __del__(self): print "destruyendo", self
...
py> x = X()
py> del x
destruyendo <__main__.X instance at 0x00A3BE90>
py> import gc
py> gc.disable()
py> x = X()
py> del x
destruyendo <__main__.X instance at 0x00B19788>

-- 
Gabriel Genellina

------------ próxima parte ------------
_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes