El día 23 de agosto de 2013 17:35, Olemis Lang <ole...@gmail.com> escribió: > Olvidé unas precisiones ... > > On 8/23/13, Chema Cortes <pych...@gmail.com> wrote: >> El día 22 de agosto de 2013 02:59, Juan BC <jbc.deve...@gmail.com> >> escribió: >>> Estoy haciendo un pequeño script que recibe otro script por parametro >>> (osea un plugin) y lo que necesito es ordenar las clases dentro de el >>> plugin en el orden que fueron declaradas: >>> >>> en un ejemplo trivial seria algo asi: >>> >>> # plugin.py >>> >>> class B(object): pass >>> class A(object): pass >>> >>> # manager.py >>> >>> import plugin >>> >>> classes = [k, v for k,v in vars(plugin).items()] >>> classes.sort(<CODIGO PARA ORDENAR B antes que A>) >> >> No es buena idea ésto que quieres hacer. > > Sí es buena idea . Se hace en Trac + Bloodhound desde hace mucho > tiempo por varias razones .
No me cabe duda que para seguimiento de un fichero de código se necesite saber el orden en que han sido declarados los objetos. Pero la creación de objetos se puede enmascarar de muchas formas, y era lo que pretendía ilustrar. La creación de una clase puede hacerse fuera de la línea temporal, incluso a través de metaclases que cambien un tipo por otro. > >> Por ejemplo, ¿dónde dirías >> que se "declaran" las clases si hago ésto?: >> >> from plugin import * >> > > Considerando q la petición original estaba relacionada con el órden de > instanciación d las clases , no veo la problemática de este ejemplo . > El import no influye en lo absoluto en la declaración de las clases , > si es q se hace en el módulo plugin (q asumo q sea el caso). > > Si se trata del # de la línea d código ... otros $20 USD ;) > >> ¿Y si me da por hacer cosas como estas? >> >> class A: pass >> >> B = A >> >> class A: pass >> > > No pasa absolutamente nada . Ud acaba de declarar dos clases , una > después de la otra , las dos con el nombre A . B es simplemente el > nombre d una variable q se registra en el namespace local . > >> Hay dos clases, pero en verdad he redeclarado 'A'. >> > > No (ver más abajo) ... desde el punto d vista del modelo de plugins > hay dos clases completamente diferentes con el mismo nombre ; lo cual > puede traer implicaciones e.g. en Trac + Bloodhound la segunda clase > nunca será configurable mediante ExtensionOption (si las dos clases > están habilitadas en trac.ini ;) . > > Ahora este comentario no es 100% preciso pq la metaclase podría > garantizar la únicidad del nombre de los plugins (clases) y remplazar > la primera instancia d A en el cache con la segunda ... pero eso ya > son circunstancias más sofisticadas . Anteriormente estaba hablando a > temperatura y presión estándar ;) > > [...] > > -- > Regards, > > Olemis - @olemislc > > Apache™ Bloodhound contributor > http://issues.apache.org/bloodhound > http://blood-hound.net > > Blog ES: http://simelo-es.blogspot.com/ > Blog EN: http://simelo-en.blogspot.com/ > > Featured article: > _______________________________________________ > Python-es mailing list > Python-es@python.org > http://mail.python.org/mailman/listinfo/python-es > FAQ: http://python-es-faq.wikidot.com/ -- Hyperreals *R "Quarks, bits y otras criaturas infinitesimales": http://ch3m4.org/blog Buscador Python Hispano: http://ch3m4.org/python-es _______________________________________________ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
