Re: [Python-es] conflicto de versiones python
En virtualenv estableces el entorno haciendo workon blender (o como lo hayas llamado) en la línea de comandos y ya está. Hernán M. Foffani El 22/08/2013, a las 19:57, lesthack lesth...@gmail.com escribió: Si, virtualenv es una buena opción, solo tendría que indicarle a Blender donde esta la ruta de su entorno aislado. Saludos ! 2013/8/22 Hernán Foffani hfoff...@gmail.com Usa virtualenv... es una opción. El 22 de agosto de 2013 09:07, lesthack lesth...@gmail.com escribió: Una forma muy sencilla de saber a que versión apunta /usr/bin/python es simplemente ejecutarlo. $ python Python 2.7.3 (default, Apr 10 2013, 05:46:21) [GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. En mi caso por ejemplo tengo predefinido la 2.7.3. Si quisieras cambiar la versión, remplaza /usr/bin/python mediante un enlace simbólico a la versión que desees. ln -sf /usr/bin/python2.6 /usr/bin/python Saludos ! 2013/8/22 Ricardo Mendoza pgsql...@gmail.com Saludos, tengo un problema que se lo atribuyo a python. Intento iniciar Blender instalado por medio de apt, en debian 7, pero al revisar veo que tengo tres versiones de python 2.6,2.7,3.2. ¿Como puedo hacer para que blender arranque con la version correcta de python?. FAQ: http://python-es-faq.wikidot.com/ Sí, yo también recomiendo virtualenv. Especialmente el wrapper: http://virtualenvwrapper.readthedocs.org/en/latest/ Le dedicas unos minutos una vez pero luego te blindas de cualquier conflicto futuro entre versiones de python y/o paquetes. -Hernán. ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/ -- ISC. Jorge Luis Hernández C. Desarrollador de Software y Tecnologías Libres Colaborador GNU/Linux Debian México http://lesthack.com.mx http://blog.debian.mx/ @lesthack ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/ ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
Re: [Python-es] determinar cual clase ha sido declarada primero
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. Por ejemplo, ¿dónde dirías
que se declaran las clases si hago ésto?:
from plugin import *
¿Y si me da por hacer cosas como estas?
class A: pass
B = A
class A: pass
Hay dos clases, pero en verdad he redeclarado 'A'.
Por lo que parece, estás creando una especie de API para creación de
plugins y te gustaría obtener el orden de los plugins tal y como son
declarados. Una solución sería usando metaclases tal como te ha
sugerido Olemis Lang. Pero las metaclases son algo complejas de
manejar y es posible evitar su uso en muchos casos desde que existen
los decoradores de clase.
Por ejemplo, puedes hacer lo siguiente:
class Plugin(object):
def __init__(self):
self.plugins = {}
def register(self, cls):
if cls.__module__ not in self.plugins:
self.plugins[cls.__module__] = []
self.plugins[cls.__module__].append(cls.__name__)
plugin=Plugin()
Y pedir a tus usuarios que registren sus plugins:
@plugin.register
class A(object):
pass
@plugin.register
class B(object):
pass
Si quieres más control, puedes crear decoradores con argumentos, por
ejemplo para pasar el nombre completo del plugin o el autor.
--
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/
Re: [Python-es] determinar cual clase ha sido declarada primero
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. Por ejemplo, ¿dónde dirías que se declaran las clases si hago ésto?: from plugin import * ¿Y si me da por hacer cosas como estas? class A: pass B = A class A: pass Hay dos clases, pero en verdad he redeclarado 'A'. Por lo que parece, estás creando una especie de API para creación de plugins y te gustaría obtener el orden de los plugins tal y como son declarados. Una solución sería usando metaclases tal como te ha sugerido Olemis Lang. Pero las metaclases son algo complejas de manejar y es posible evitar su uso en muchos casos desde que existen los decoradores de clase. La elección entre meta-clases y decoradores de clases , en este caso , puede ser a gusto de la persona en cuestión . De hecho en teoría Trac podría facilitar las dos variantes : - metaclases para el sistema d plugins ComponentMeta (Component + ComponentManager) - decoradores de clases para declara las interfaces q implementa una clase (i.e. implements) Nótese que en este caso la diferencia entre las dos variantes consiste en expresar intrínsecamente el comportamiento esperado de las clases (registrarse en orden en el cache global, añadir el comportamiento esperado del sistema d plugins e.g. implement ParametricSingleton pattern per ComponentManager, etc ...) vs el comportamiento específico d una clase en cuestión (registrarse en orden en el cache de la interface específica ...) Como se puede ver no son conceptos equivalentes . Las meta-clases participan en herencia , añaden comportamientos a los meta-objetos q representan las clases (clases) y sus instancias (objetos) ; además son tipos . Los decoradores son modificadores más puntuales ... quizás parecidos a la situación descriptores vs __getattr__ El hecho de poner __metaclass__ en el cuerpo de la clase se puede solucionar haciendo la asignación en una clase base (e.g. trac.core.Component) y ya no es necesario repetirlo en las sub-clases . De hecho , en Trac + Bloodhound el hecho d tener ComponentMeta y todo el modelo meta es transparente ... [...] -- 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/
Re: [Python-es] determinar cual clase ha sido declarada primero
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 . 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/
Re: [Python-es] determinar cual clase ha sido declarada primero
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/
Re: [Python-es] determinar cual clase ha sido declarada primero
On 8/23/13, Chema Cortes pych...@gmail.com wrote: El día 23 de agosto de 2013 16:31, Olemis Lang ole...@gmail.com escribió: [...] Nótese que en este caso la diferencia entre las dos variantes consiste en expresar intrínsecamente el comportamiento esperado de las clases (registrarse en orden en el cache global, añadir el comportamiento esperado del sistema d plugins e.g. implement ParametricSingleton pattern per ComponentManager, etc ...) vs el comportamiento específico d una clase en cuestión (registrarse en orden en el cache de la interface específica ...) Como se puede ver no son conceptos equivalentes . Las meta-clases participan en herencia , añaden comportamientos a los meta-objetos q representan las clases (clases) y sus instancias (objetos) ; además son tipos . Los decoradores son modificadores más puntuales ... quizás parecidos a la situación descriptores vs __getattr__ El hecho de poner __metaclass__ en el cuerpo de la clase se puede solucionar haciendo la asignación en una clase base (e.g. trac.core.Component) y ya no es necesario repetirlo en las sub-clases . De hecho , en Trac + Bloodhound el hecho d tener ComponentMeta y todo el modelo meta es transparente ... No he dicho que los decoradores fueran los sustitutos de las metaclases, sino que pueden evitar tener que usarlas en determinadas situaciones. No era mi intención sugerir q antes se había dicho alguna cosa . Yo solo estaba complementando los comentarios anteriores para brindar más elementos a la hora de decidir por una u otra variante ;) Las metaclases ofrecen la posibilidad de crear un modelo de datos bastante consistente para el problema que necesites tratar; pero, en mi opinion, tienen un verdadero problema con la herencia ya que las metaclases no tienen herencia múltiple. Si necesitas combinar dos modelos de datos distintos, cada uno con una metaclase, necesitarás crear una supermetaclase común y modificar buena parte del código. En cambio, los decoradores de clases se pueden encadenar uno tras otro sin más preocupaciones. Por otro lado, el valor de '__metaclass__' no tiene porque ser una clase, ya que podría ser cualquier callable, Entonces , en buena lid , ya no sería una metaclase sino un class factory o quizás alguna otra cosa más complicada dependiendo d los detalles d implementación . La meta-clase es un concepto abstracto d la POO q va más allá del hecho d q la variable en Python se llame __metaclass__ y acepte cualquier callable . ;) incluso una función, lo que se asemejaría bastante a lo que hace un decorador. +1 ... la única diferencia creo q sería la propagación de la meta-clase a las sub-clases mediante herencia , q es lo q no se logra con decoradores por ser estos un artificio sintáctico del lenguaje . Quizás hay resultados q solo se logran d forma *más correcta* al nivel de las meta-clases Por ejemplo, recuerdo ahora las implementaciones del patrón Singleton (y similares e.g. ParametricSingleton como es el caso d trac.core.Component) basados en la redefinición de __call__ en la metaclase , pero no es el único caso . D hecho , un sistema d plugins q *tiende* a ser compuesto por singletons (q puede ser un caso muy frecuente según mi experiencia) frecuentemente necesita meta-clase, porque es el mecanismo más efectivo q existe en el lenguaje para controlar la creación d instancias d las clases (... ya sé, ya sé ... __new__ + __init___ = no son suficientes , y al final son el resultado d las reglas q impone type__call__ , redefiniéndolo se puede implementar un sistema completamente nuevo a partir d una meta-clase diferente e.g. invocar un método con el mismo nombre d la clase à la C# en vez d __init__) No veo que sea tanta la diferencia entre uno y otro como lo pones, ... dependiendo d las circunstancias puede q no tanto ... no m atrevo a profundizar más pq realmente no sabemos cuál es el caso d uso y los requisitos reales q están involucrados en la pregunta original . con la excepción de que los decoradores son más explícitos. Y éso es bueno para según qué cosas. No hay desacuerdo ; solo q es bueno aclararlo . [...] -- 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/
