Re: [Python-es] De paquetes y de huevos
El 30/09/16 a las 13:31, Chema Cortes escribió: Descarté máquinas virtuales y docker en su día, porque tengo mucha dependencia de la GPU (a través de opencl). En máquinas virtuales he tenido muchos problemas cuando he probado (todo muy experimental), y medir los tiempos necesito que todo sea cuando más cercano al metal mejor... Repecto a docker, lo desestime por la experiencia con las máquinas virtuales... Aunque a veces van asociados, docker no es una máquina virtual. La confusión viene de que docker corre nativamente en linux (de 64 bits), por lo que se necesitan máquinas virtuales en mac y windows. Pero si trabajas en linux, no necesitas virtualizar nada, tan sólo lanzar docker como servicio (y con rkt ni eso). Cuando usas virtualenv, juegas con el PATH del entorno para posicionar unas versiones de módulos sobre otras; con docker, juegas con el sistema de ficheros BTRFS para posicionar unos directorios por encima de otros. Si buscas algo más cercano al metal, docker parece mejor preparado que virtualenv. Si, si estuve investigando y leyendo sobre lo de usar lxc, etc.. pero estuve leyendo de gente que le había dado problemas, y como venía de hacer tantas pruebas infructuosas con las máquinas virtuales, por eso lo dejé en vía muerta... puede que tengas razón y tenga que probar más sobre docker... pero por ahora me decanto por montar la infraestructura con virtualenvs emulando las distros. P.D: Me apunto lo de conda para usarlo. Gracias a todos por vuestros aportes. Un cordial saludo. ___ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
Re: [Python-es] De paquetes y de huevos
El 30/09/16 a las 11:49, Chema Cortes escribió: El vie., 30 sept. 2016 a las 10:53, Antonio Beamud Montero (<antonio.bea...@gmail.com <mailto:antonio.bea...@gmail.com>>) escribió: Para eso necesitaría meter las mismas versiones que llevan las distintas distribuciones, y poder crear un virtualenv ubuntu12.04 (por ejemplo), instalando ahí con pip las mismas versiones que se instalan via apt-get en ubuntu 12.04... Si entiendo bien, pretendes mantener versiones distintas según las distintas distribuciones de linux. Es completamente una locura. Si ya es complicado mantener versiones para distintas plataformas, ampliar el espectro a todas las posibles configuraciones es imposible. Por lo menos tendrás versiones distintas para python2 y python3, además de versiones diferentes de otras librerías principales (gtk2/gtk3, qt4/qt5, mysql/mariadb,). Si, bueno, no para todas las distros de linux, solo 2 o 3, realmente poder ir probando posibles migraciones. Tengo experiencia en la pesadilla que supone mantener para varias distros, pero es impepinable por ahora... Este problema es común a todos los lenguajes de programación y la solución es docker. No sé porqué lo has descartado tan pronto. Si no te parece liviano coreOS o rancherOS, es que no tenemos el mismo concepto de "liviano". Hoy en día, incluso se puede asociar la ejecución de un contendor docker con la carga de un módulo python, similar a lo que sería la carga de una librería dinámica, pero sin los problemas de dependencias con librerías del sistema. Por ahí va el futuro de python y de muchos otros lenguajes, aunque no sabría decirte si será docker, rkt u otro mejor. Descarté máquinas virtuales y docker en su día, porque tengo mucha dependencia de la GPU (a través de opencl). En máquinas virtuales he tenido muchos problemas cuando he probado (todo muy experimental), y medir los tiempos necesito que todo sea cuando más cercano al metal mejor... Repecto a docker, lo desestime por la experiencia con las máquinas virtuales... La conclusión a la que he llegado, es que lo más sencillo en mi caso sería, poder generar un virtualenv, con una plantilla de los paquetes que incluye una distribución en concreta, meter mi soft, lanzar los tests y ver donde da problemas. Si puedo adaptarlo para que funcione sin problemas en varias distros sin necesidades especiales, mejor, e intentar generar paquetes para esa distro... El único coñazo es tener que instalar la distro (o buscar el listado de paquetes en la web), sacar los de python de los que dependo, sus versiones y crear el virtualenv con él... Sino darle la oportunidad a docker, para distribuirlo... Un saludo. -- Hyperreals *R "Quarks, bits y otras criaturas infinitesimales": http://blog.ch3m4.org <http://ch3m4.org/blog> ___ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/ ___ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
Re: [Python-es] De paquetes y de huevos
El 29/09/16 a las 22:09, Mario Lacunza escribió: Una pregunta de donde sacas este argumento? ese mas parece el manejo de Windows y no de Linux. ¿A que argumento te refieres? Cuando un paquete A necesita la lib1.2 la instala (si esta disponible en el repositorio) Sino la compilas. Si en el OS está ya instalada la lib1.3 esta sigue funcionando y los programas q la necesiten seguiran apuntando a ella y no a lib1.2 (precisamente el DLL Hell de windows) AHORA si te refieres a UNICAMENTE a subprogramas de o para python entonces usas el virutalenv y listo. Cuál es el drama? Todo me refiero a librerias y programas de python. Intento evitar todo eso, mezclar paquetes/librerías instaladas via apt-get y las instaladas via pip. Imagina que la distribución instala via apt-get un paquete paqX, que depende de la librería >=lib1.3. Tu ahora instalas tu egg que depende de la librería lib2.9 (que hace cambios en el api de la lib), esa aplicación paqX te puede empezar a dar problemas, porque resuelve dependencias contra la lib2.9 (incluso peores casos donde no se especifica en los requerimientos que versión necesita para funcionar). Esto es precisamente lo que intento evitar, y lo que me gustaría es poder simular todas las dependencias que tienen una distribución, y poder probar paquetes que no están en la distribución para ver que resuelve bien dependencias y no genera conflictos. No hay ningún drama, la idea final es que intento no mezclar paquetes instalados con apt-get y con pip, porque al final, lo que quiero es poder crear paquetes para las distribuciones que se instalen via apt-get, pero antes quiero probar todo en un entorno ligero via virtualenv. (no se si me explico). Para eso necesitaría meter las mismas versiones que llevan las distintas distribuciones, y poder crear un virtualenv ubuntu12.04 (por ejemplo), instalando ahí con pip las mismas versiones que se instalan via apt-get en ubuntu 12.04... Saludos / Best regards Mario Lacunza Email:: mlacu...@gmail.com <mailto:mlacu...@gmail.com> Personal Website:: http://www.lacunza.biz/ Hosting:: http://mlv-host.com/ Skype: mlacunzav Lima - Peru El 29 de septiembre de 2016, 08:33, Antonio Beamud Montero<antonio.bea...@gmail.com <mailto:antonio.bea...@gmail.com>> escribió: Como ya sabéis las distribuciones de linux empaquetan una serie de librerías y utilidades de python en una versión concreta. Cuando desarrollas algo sobre python, y necesitas alguna librería que no está disponible en paquete para tu distribución, normalmente tiras de huevos (que mal suena eso :D) y lo instalas vía pip/easy_install... Esto lleva a que si no tienes cuidado, esa nueva librería que instalas, puede tirar de dependencias y actualizar alguna de las librerías que ya tenías previamente instaladas vía sistema de paquetes, pudiendo provocar mal-funcionamientos en otras aplicaciones como efecto colateral. ___ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/ ___ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
[Python-es] De paquetes y de huevos
Como ya sabéis las distribuciones de linux empaquetan una serie de librerías y utilidades de python en una versión concreta. Cuando desarrollas algo sobre python, y necesitas alguna librería que no está disponible en paquete para tu distribución, normalmente tiras de huevos (que mal suena eso :D) y lo instalas vía pip/easy_install... Esto lleva a que si no tienes cuidado, esa nueva librería que instalas, puede tirar de dependencias y actualizar alguna de las librerías que ya tenías previamente instaladas vía sistema de paquetes, pudiendo provocar mal-funcionamientos en otras aplicaciones como efecto colateral. Una solución a este problema es usar virtualenv, y acotar el entorno de aplicación. La idea es desarrollar la app usando en la medida de lo posible las versiones empaquetadas de cada distribución, para en un momento dado, empaquetarlas directamente en paquete de la distribución. El tema es desarrollar/probar sobre múltiples distribuciones y automatizar todos estos tests sin tener que irte a máquinas virtuales para cada distribución (incluido docker), sino algo más liviano... es decir, crear un virtualenv para cada distribución en la que quieras probar tu app, con todas esas librerias/utilidades que van preempaquetadas, tenerlas en la misma versión en tu virtualenv y poder acotar problemas, etc... Después de todo este rollo, viene la pregunta ¿Sabéis si existe algún sitio donde se publiquen todos los paquetes python que instala cada distribución en un formato tipo al que genera pip freeze para poder regenerar el entorno? Y ya puestos, si tenéis experiencia con algún entorno de tests, que pros y contras les veis... Un cordial saludo. ___ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
Re: [Python-es] Servidores web en python
El 25/09/16 a las 13:51, Chema Cortes escribió: Se puede dar un buen servicio con apache, pero conseguir que sea escalable es complicado. Mientras, nginx se adapta muy bien a los incrementos de demandas, sobre todo si se trata de enviar streams de datos. Hola Chema, ¿en que casos crees que apache no escala bien? Hasta ahora, los casos que me he encontrado yo, no eran problema de apache, sin el backend detrás de él. Un cordial saludo. ___ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
Re: [Python-es] Internalización en Python
El 28/10/15 a las 21:29, Rafael Cantos escribió: Buenas a todos ¿Qué me recomendais para internalizacionar un programa en python? Aún no he empezado a desarrollarlo. Mi Linux tiene la versión 2.7.9. Por lo que he visto en la documentación oficial, es gettext, pero no sé si hay alternativas y si son mejores. he visto algún módulo para python 3, pero como no tengo esta versión (y creo que me quedo en la 2.7.9 por compatibilidad). Échale un vistazo a Babel (http://babel.pocoo.org/). La he usado en varios proyectos y está muy bien, no solo para internacionalización, sino también para localización. Un saludo. ___ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
Re: [Python-es] ¿Código de python que merece ser estudiado?
El 04/08/15 a las 13:56, Chema Cortes escribió: El 3 de agosto de 2015, 21:10, Carlos Zuniga carlos@gmail.com mailto:carlos@gmail.com escribió: 2015-08-02 22:01 GMT-05:00 AGTUGO agt...@gmail.com mailto:agt...@gmail.com: Les pido compartir aquel proyecto donde hayan visto un código python que merece la pena ser estudiado: -Por su belleza, simplicidad. -Por el conocimiento que adquieres después de estudiarlo. -Por lo bien comentado que esta. Yo recomendaría un proyecto que con el paso de los años se ha vuelto bastante grande, pero que podría ser un buen ejemplo de como crear una arquitectura de componentes reusables, esa es el zope toolkit (muchos de esos componentes se están usando como base para otros proyectos, por ejemplo zope.interface se usa intensivamente en el core de pyramid, que permite llevar a cabo la programación por contrato, con conceptos tan atractivos como los adaptadores) Aquí toda la lista de paquetes: http://docs.zope.org/zopetoolkit/releases/packages-trunk.html Y por ejemplo, uno de los componentes nucleares, el código para el citado zope.interface: https://github.com/zopefoundation/zope.interface ___ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
Re: [Python-es] Eficiencia de las listas
El 05/08/13 21:54, Chema Cortes escribió: Últimamente, estoy realizando estudios sobre la eficiencia de distintos códigos python. Mirando qué tipo de colección podía ser más eficiente según qué tareas, me encuentro con el siguiente párrafo en la documentación de [deque][1]: Deques support thread-safe, memory efficient appends and pops from either side of the deque with approximately the same O(1) performance in either direction. Though list objects support similar operations, they are optimized for fast fixed-length operations and incur O(n) memory movement costs for pop(0) and insert(0, v) operations which change both the size and position of the underlying data representation. He comprobado que, efectivamente, el costo de insertar elementos al principio de una lista es mucho mayor que añadir elementos al final de la lista (x1). En estos momentos , necesito trabajar con listas de números muy largas ( 10e6 elementos) para trocear en dos pedazos, invertir uno de ellos y volverlos a empalmar (método 2-opt). Una forma de expresarlo: L[i+1:j+1] = L[j:i:-1] con i+1j que equivale a: L[:i] + L[j:i:-1] + L[j+1:] Esta última expresión, aunque más clara, es poco eficiente al tener que crear una nueva lista partiendo de tres sublistas intermedias. Los elementos no cambian de valor y tampoco cambia el tamaño de la lista. Parece que la lista es la estructura más eficiente para esta tarea (por lo que cuenta la documentación) siempre que no se modifique en tamaño. Pero me pregunto si hay algún modo de hacer este manejo más eficiente, tal vez usando alguna otra estructura, en python o numpy, que mejore estas tareas de corte y empalme. Intuyo que con arrays se reducen las necesidades de memoria, pero en estos momentos, la memoria es lo que menos me preocupa. Busco un método genérico que pueda valer para cualquier otro tipo de datos (eg: lista de vectores). Yo me decanté por usar numpy para resolver este tipo de problemas, aunque mis listas eran un orden de magnitud más pequeñas, después de hacer varias pruebas, el uso de las listas para operaciones simples, es tanto o más eficiente usando listas de python que crear arrays en numpy (bueno dependiendo de la operación), pero yo necesitaba métodos como 'diff', 'where', etc.. que si que marcaban diferencias respecto a mis anteriores implementaciones. Estaré muy atento a las conclusiones que llegues :-) Un saludo. ___ 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] recomendacion para comunicacion cliente-servidor, ambos en la misma maquina
El 26/10/12 18:46, Carlos Zuniga escribió: 2012/10/26 Jose Caballero jcaballero@gmail.com: (perdon, he enviado el mensaje a medias por error) El 26 de octubre de 2012 12:21, Jose Caballero jcaballero@gmail.com escribió: Hola, tengo un proceso 'daemon' escrito en python. Esta corriendo el 100% del tiempo. Necesitaria que algunos scripts que se ejecutan desde la linea de comandos, tambien escritos en python, sean capaces de enviarle mensajes a ese daemon. No hay problemas de seguridad ni de autenticacion. Ambos procesos se ejecutan en la misma maquina, y se presupone que las etapas de autenticacion/autorizacion ya se han hecho antes. Por otro lado, al estar en la misma maquina, y por tratarse de mensajes muy cortos, no hay problemas de eficiencia. Cual es la forma mas sencilla que me recomiendan para implementar la comunicacion? Una busqueda en google me da dos posibles alternativas (o quizas son la misma y a mi me parecen diferentes): - usar un servidor http (puede el ser el que trae python) y escuchar llamadas hechas por ejemplo con libcurl - sockets. Ando algo perdido. Cualquier sugerencia (o link donde pueda aprender) es mas que bienvenida. Una opción es utilizar twisted: http://twistedmatrix.com/trac/ Y una más para que invesgues es usar dbus. Saludos Otras opciones son: Puedes echarle un vistazo a Pyro, si ambas partes están implementadas en python: http://pypi.python.org/pypi/Pyro4 Más flexible sería usar CORBA, por ejemplo omniORB, lo que te permite usar diferentes lenguajes y es muy, muy rápido. Un saludo. ___ 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] Saludos y Pregunta. (Django vs Web2py)
Rafael Enrique Ortiz Guerrero escribió: Saludos Cordiales. Soy nuevo en esta lista, pero he usado python desde hace un buen tiempo, y aunque no soy muy bueno me encanta este lenguaje. Estoy planeando empezar a utilizar un framework para hacer una aplicación Web y quisiera saber que me recomendarían Django o Web2py ? , me gustaría tener razones muy solidas para usar uno u otro pero no tengo conocimientos profundos de arquitectura de software. Pylons ;-) Gracias de antemano por la atención prestada!. Rafael Ortiz ___ 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] Liado con SOAP
Daniel Garcia escribió: El mar, 08-06-2010 a las 13:06 +0200, Oswaldo Hernández escribió: Hola, Te recomiendo pasar de SOAP, e incluso de XMLRPC y utilizar una api http rest + json o xml, similar a la api de twitter [1], todo se basa en una petición a una url (GET o POST) y los datos/respuestas vienen en xml o en json, o incluso en los dos dependiendo de la extensión de la url, por ejemplo: http://api.twitter.com/1/statuses/public_timeline.json Esto es compatible con casi todos los lenguajes de manera fácil, casi sin necesidad de añadidos. [1] http://apiwiki.twitter.com/Twitter-API-Documentation +1 ___ 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] Threads con operaciones I/O en Python
lasizoillo escribió: El día 8 de junio de 2010 16:11, Antonio Beamud Montero antonio.bea...@gmail.com escribió: Fél Si los hilos son de proceso están muy ligados a E/S te recomiendo gevent (http://www.gevent.org/). El api es muy similar a trabajar con hilos, pero por debajo usa libevent, para trabajar de forma asincrona. No entiendo las ventajas de usar gevent para este caso concreto. Entendería usarla si se dieran las siguientes condiciones: * No va a tener problemas con librerias que no cooperan * Va a necesitar de hilos a cascoporro y quiere minimizar el overhead * Va a sacar partido de usar los pollers (kevent, epoll, ...) que proporciona libevent. * Evitar cambios de contexto en los hilos le va a suponer una ventaja El primer punto lo veo conflictivo en su caso. Porque va a usar librerias que no van a cooperar con los greenlets. Así que usar gevent le puede dar más problemas que ventajas. Cierto, he leido su mensaje un poco por encima y no me he fijado demasiado, me he guiado más por el asunto del mensaje. No creo que vaya a necesitar de muchos hilos. Así que el número de hilos python a usar no debería suponer mucho overhead. Tampoco creo que vaya a notar mucha diferencia entre un poller como select o uno como epoll si el numero de eventos registrados es mínimo. Bueno, aqui depende de como lo programes, puedes lanzar un Greenlet por acción, evento, lo que sea, son muy ligeros. ¿Me estoy perdiendo algo del maravilloso framework gevent? ¿De qué forma ventajosa se podría utilizar en este caso concreto? También es verdad que si usa gevent mediante monkey-patching la prueba es gratis ;-) No he he seguido todo el hilo, como te comentaba. Puede que si mira gevent, a lo mejor diseña de otra forma su aplicación o le da alguna idea de como resolver algún problema que se pueda presentar, bien ahora, bien en el futuro. Saludos. ___ 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] Dive Into Python Must Die
FYI via reddit :) http://oppugn.us/posts/1272050135.html ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
