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

[Milton Galo Patricio Inostroza Aguilera]

El día 2 de mayo de 2008 20:51, Gabriel Genellina
<gagsl-py2 en yahoo.com.ar> escribió:
> 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 :)


Aja!!...entonces es posible tratar de hacer lo que "no se debe
hacer"...gracias por la guia...pero creo que lo mas respetuoso es
primero programar un tipo de datos el cual implemente el asunto del
identificador, ver como funciona....y luego ser irrespetuoso y hacer
modificaciones que estamos claros que no son buenas hacerlas, pero asi
se va aprendiendo en este mundo de la programacion

>
>
>
> > 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>

interesante

>
>  --
>  Gabriel Genellina
>
>
> _______________________________________________
>  Lista de correo Python-es
>  http://listas.aditel.org/listinfo/python-es
>  FAQ: http://listas.aditel.org/faqpyes
>



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