From jcea en jcea.es Fri Jul 2 22:04:55 2021 From: jcea en jcea.es (Jesus Cea) Date: Sat, 3 Jul 2021 04:04:55 +0200 Subject: [Python-es] How to generate Roman style mosaics with Python Message-ID: Por si a alguien le interesa: -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea en jcea.es - https://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea en jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz ------------ próxima parte ------------ Se ha borrado un mensaje adjunto que no está en formato texto plano... Nombre : OpenPGP_signature Tipo : application/pgp-signature Tamaño : 495 bytes Descripción: OpenPGP digital signature Url : From felipe en felipem.com Mon Jul 5 15:30:25 2021 From: felipe en felipem.com (Felipe Maza) Date: Mon, 5 Jul 2021 21:30:25 +0200 Subject: [Python-es] Sistemas de colas Message-ID: Hola, Llevo unos días viendo diferentes programas para gestionar sistemas de colas y, en principio, creo que casi todos parecen complejos para lo que necesito. Mi problema a resolver es el siguiente, tenemos un modelo de predicción que se ejecuta periódicamente y también bajo demanda del usuario. Ese modelo se ejecuta en un solo hilo y tarda bastantes minutos en completar la tarea. Por tanto, puedo tener varias ejecuciones simultáneas siempre que no excedamos el número de cores disponibles, ya que en ese caso se vuelve el sistema excesivamente lento. Al modelo se le invoca a través de una pequeña api hecha con flask. En el futuro puede que haya otros modelos en la misma máquina. Hace un par de años para un problema similar ya me programé mi propio gestor de colas rudimentario,pero ahora busco algo que sea estable, con pocos bugs, mantenible, etc. Las características que (creo que) necesito son: - Encolar tareas (logicamente) - Tener colas con diferente prioridad (manuales, periódicas). - Registrar la salida, tanto si ha tenido éxito como si ha tenido errores. - (opcional) En un futuro ejecutar otras apis con modelo en la misma máquina. Lo primero que he explorado ha sido Celery, y es impresionante el montón de posibilidades que ofrece, tantas que ir poco más de los ejemplos iniciales me parece muy complejo para solucionar el problema anterior. Me da la sensación que hay que controlar un montón de aspectos para montarlo y mantenerlo correctamente; y que cuando aparezca algún error no va a ser rápido dar con la solución. Después de mirar otras alternativas, con la que parece que he montado una primera versión que parece que me lo soluciona, es Redis Queue ( https://python-rq.org/). La forma en la que utiliza Redis es relativamente simple, y más o menos ofrece lo que necesito. En el tema de los worker creo que ahí flojea un poco, pues parece que tendré que gestionar manualmente cuántos hay arrancados y si no se han muerto. ¿Tenéis experiencia resolviendo algún problema similar? ¿Creéis que merece la pena el esfuerzo para aprender celery (u otra solución) para algo que no debería ser muy complejo? ¿Redis os parece buen motor o debería ir a Rabbitmq? Nunca había usado ninguno de ellos. ¿Cómo gestionais el tema de los worker? Seguro que es más sencillo de lo que creo. Cualquier comentario que queráis hacer será bienvenido. Gracias, Un saludo. -- Felipe Maza Fernández felipe en felipem.com 622 338 121 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From lasizoillo en gmail.com Mon Jul 5 19:29:36 2021 From: lasizoillo en gmail.com (lasizoillo) Date: Tue, 6 Jul 2021 01:29:36 +0200 Subject: [Python-es] Sistemas de colas In-Reply-To: References: Message-ID: Buenas, Te contesto entre lineas y perdona si me pongo un poco pedante o chapas. Pero creo que es mejor no dar nada por hecho cuando hay más de un sistema corriendo a la vez. El lun, 5 jul 2021 a las 21:31, Felipe Maza () escribió: > Hola, > > Llevo unos días viendo diferentes programas para gestionar sistemas de > colas y, en principio, creo que casi todos parecen complejos para lo que > necesito. > > Mi problema a resolver es el siguiente, tenemos un modelo de predicción > que se ejecuta periódicamente y también bajo demanda del usuario. Ese > modelo se ejecuta en un solo hilo y tarda bastantes minutos en completar la > tarea. Por tanto, puedo tener varias ejecuciones simultáneas siempre que no > excedamos el número de cores disponibles, ya que en ese caso se vuelve el > sistema excesivamente lento. Al modelo se le invoca a través de una pequeña > api hecha con flask. En el futuro puede que haya otros modelos en la > misma máquina. > > Hace un par de años para un problema similar ya me programé mi propio > gestor de colas rudimentario,pero ahora busco algo que sea estable, con > pocos bugs, mantenible, etc. > > Las características que (creo que) necesito son: > - Encolar tareas (logicamente) > Qué garantías de entrega quieres. Idealmente 1 vez y sólo una vez, pero en el mundo real debes elegir entre al menos una vez y como máximo una vez. Si tu tarea no es idempotente ese al menos una vez te puede generar problemas. Pero, ¿es correcto perder algún trabajo para asegurar que no llegan duplicados? https://docs.celeryproject.org/en/stable/userguide/calling.html#message-sending-retry - Tener colas con diferente prioridad (manuales, periódicas). > Colas con prioridad o diferentes rutas de mensajes para dimensionar de una forma u otra los workers? https://docs.celeryproject.org/en/master/faq.html#does-celery-support-task-priorities > - Registrar la salida, tanto si ha tenido éxito como si ha tenido errores. > Qué ocurre si no llega a haber resultado? Imagina que tu tarea consume mucha memoria y es matada por el OOM killer de linux (si es que usas linux, si no imagina otro percance similar). O qué pasa si se apaga la máquina? Quieres que se considere que la tarea no ha sido procesada y se reintente si no has hecho ack de la tarea? Qué pasa si cada vez que reintentas la tarea se genera un problema de memoria y nunca se hace ack de ella? https://docs.celeryproject.org/en/stable/faq.html#why-do-workers-delete-tasks-from-the-queue-if-they-re-unable-to-process-them https://docs.celeryproject.org/en/stable/faq.html#should-i-use-retry-or-acks-late https://medium.com/@hengfeng/how-to-create-a-dead-letter-queue-in-celery-rabbitmq-401b17c72cd3 Qué ocurre si guardas los resultados de las tareas en un redis y este se cae? Lo configuras con persistencia a disco? Cuánto tiempo te puedes permitir perder resultados (que todavía persisten solo en memoria) ante una caida del Redis? > - (opcional) En un futuro ejecutar otras apis con modelo en la misma > máquina. > En la misma máquina o en otra no es problema. Y separar los workers o no hacerlo tampoco lo sería. Este es el único requisito que me ha parecido simple. > > > Lo primero que he explorado ha sido Celery, y es impresionante el montón > de posibilidades que ofrece, tantas que ir poco más de los ejemplos > iniciales me parece muy complejo para solucionar el problema anterior. Me > da la sensación que hay que controlar un montón de aspectos para montarlo y > mantenerlo correctamente; y que cuando aparezca algún error no va a ser > rápido dar con la solución. > Es muy complejo, posiblemente demasiado complejo. Pero son complejidades que hacen que se adapte a muchos tipos de problemas diferentes. Algunos ejemplos: - Cuando tienes tareas livianas ir haciendo prefetch de varios mensajes y guardarlos en una cola junto al worker te quita tiempos de latencias. Cuando tienes tareas pesadas (tu caso) ese prefetch puede hacer que un worker acapare tareas mientras otros están ociosos https://docs.celeryproject.org/en/stable/userguide/optimizing.html#prefetch-limits - Si tu worker usa librerías con memory leaks, refrescar el worker después de algunas tareas puede darte la estabilidad que no tienen tus dependencias. Si no puedes configurar esto (en celery es configurable) te tocará a ti reiniciar los workers de vez en cuando o meter un monitor que los levante cuando mueran. - Hay quien necesita y quien no montar workflows sobre las tareas https://docs.celeryproject.org/en/stable/userguide/canvas.html - Si tienes tareas programadas o recurrentes con celery puedes usar celery beat y no depender del cron de tu sistema. - ... > > Después de mirar otras alternativas, con la que parece que he montado una > primera versión que parece que me lo soluciona, es Redis Queue ( > https://python- rq .org/ > ). La forma en la que utiliza Redis es > relativamente simple, y más o menos ofrece lo que necesito. > En el tema de los worker creo que ahí flojea un poco, pues parece que > tendré que gestionar manualmente cuántos hay arrancados y si no se han > muerto. > > Si hay una opción más simple que celery y que resuelve tus requisitos (presentes y futuros) tírate de cabeza a ella. Si no sabes cuáles son tus requisitos celery es una opción conservadora: cuando sepas que requisitos tienes posiblemente solo tengas que cambiar la config y en algún caso raro y marciano (posiblemente nunca) hacer cosas con los blueprints para extenderlo. > > ¿Tenéis experiencia resolviendo algún problema similar? ¿Creéis que merece > la pena el esfuerzo para aprender celery (u otra solución) para algo que > no debería ser muy complejo? ¿Redis os parece buen motor o debería ir a > Rabbitmq? Nunca había usado ninguno de ellos. ¿Cómo gestionais el tema de > los worker? Seguro que es más sencillo de lo que creo. > Cualquier comentario que queráis hacer será bienvenido. > > Celery es muy complejo. Estas son sus partes y como extenderlo https://docs.celeryproject.org/en/latest/userguide/extending.html Pero aparte de complejo tiene cosas que no aprovechan esa complejidad y resultan complejas de usar correctamente, por ejemplo configurar celerybeat en alta disponibilidad https://github.com/celery/celery/issues/251 Es por eso que odio con todas mis fuerzas celery. Por un lado tiene un nivel de robustez y adaptabilidad a distintos tipos de trabajo que es digno de admirar. Por otro es fácil, muy fácil, pegarse un tiro en un pié si lo usas mal. Si no fuese porque todavía no he encontrado una alternativa mejor (aunque tengo algún candidato para ser probado) dejaría de usarlo ya, pero por el momento es lo menos malo que conozco. Así que por ahora, y con la boca pequeña, recomiendo celery. Un saludo, Javi > > Gracias, > > Un saludo. > > -- > Felipe Maza Fernández > felipe en felipem.com > 622 338 121 > _______________________________________________ > Python-es mailing list > Python-es en python.org > https://mail.python.org/mailman/listinfo/python-es > ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From virako.9 en gmail.com Tue Jul 6 03:12:05 2021 From: virako.9 en gmail.com (Victor Ramirez) Date: Tue, 6 Jul 2021 08:12:05 +0100 Subject: [Python-es] Tertulia python, martes 6 de Julio a las 21:30 CET Message-ID: Hola, Se convoca la Tertulia de la semana, martes 6 de Julio a las 21:30 CET. Seguimos buscando a alguien con ganas de editar audio, mientras se sigue publicando el excelente trabajo que realizó Pablo en https://podcast.jcea.es/python/ Aclaramos que cuando nos referimos a poca paga, económicamente se refiere a 0 ?, que viene siendo lo que genera el podcast, es un hobby y como tal, pues nos da trabajo que se compensa con mucha satisfacción pero sin dinero. Por lo demás, nada más que animaros a conectaros y participar en estas amenas tertulias, no se requieren conocimientos avanzados, solo ganas de charlar con más gente. Y el texto de siempre: La charla será en la sala "py2021" de jitsi: https://meet.jit.si/py2021 . Se puede entrar con cualquier navegador moderno. También hay aplicaciones para Android e iOS. Bloquearé la sala con clave, que retiraré a las 21:30 para permitir el acceso público. Algunos detalles: - Se grabará el audio de la conversación con vistas a una difusión pública posterior (tipo podcast). Entendemos que los participantes están de acuerdo en ser grabados (el audio, no grabo vídeo). Si alguien tiene pegas con esto lo puede comentar al principio de la tertulia. De todas maneras lo recordaré al empezar. - Se agradece que se entre con vídeo, aunque el sonido esté silenciado, porque hablar a una pantalla llena de recuadros negros resulta confuso y desagradable. No es imprescindible, pero es de agradecer. - A poder ser, ten el sonido silenciado si no estás hablando. Procura que tu audio tenga calidad y no meter ruido ambiente. Procura usar auriculares para evitar el retorno. - La tertulia no tiene tema definido más allá de hablar de Python como lenguaje. Lo más fácil es romper el hielo con algún problema o algún descubrimiento reciente con el que te hayas tropezado con el lenguaje. Sería interesante que trajeras algo pensado. - ¡Trae tu tema! Un saludo. ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From contacto en nekmo.com Tue Jul 6 18:29:20 2021 From: contacto en nekmo.com (Nekmo) Date: Wed, 7 Jul 2021 00:29:20 +0200 Subject: [Python-es] [Py-ES] Sistemas de colas In-Reply-To: <05E1940B-F836-465F-B8E4-7CF931D8A749@gmail.com> References: <05E1940B-F836-465F-B8E4-7CF931D8A749@gmail.com> Message-ID: Para nada ha sido pedante o chapas Lasizoillo, es genial contar con comentarios tan completos y tan bien documentados, ¡gracias! :) Nunca me había parado a mirar sobre extender Celery, y ahora ya sé por dónde empezar. Por curiosidad, ¿para qué habéis tenido la necesidad de ampliarlo? En mi caso uso Celery por los mismos motivos, ya que se adapta a las necesidades de cualquier proyecto sin necesidad de conocer todos sus requerimientos. Además, al usarlo en más proyectos, adquiero conocimiento reaprovechable. Otra ventaja es su robustez, su documentación y añadiría su monitorización. Es importante monitorizar el correcto funcionamiento de las colas, y para Celery al ser tan utilizado hay muchos recursos. Un cordial saludo: -- Nekmo. Sitio web: http://nekmo.com Dirección de contacto: contacto en nekmo.com XMPP/Jabber: contacto en nekmo.com Google+: Nekmo Com El mar, 6 jul 2021 a las 8:17, Federico Mon () escribió: > Es un buen apunte, yo no he trabajado con procesos que consumiesen tanta > RAM > > On July 5, 2021 11:12:24 PM GMT+02:00, Jose Manuel > wrote: >> >> Quería señalar que si te quedas sin RAM y el trabajo está ya lanzado, si >> te quedas sin el. >> >> Y aunque hagas try, except finally. Al ser matado por el sistema no lo >> captura ni el try ni sentry. >> >> Hablo de creación de ficheros de más de 10GB . >> >> Y lo resalto porque bueno, parece obvio cuando ya lo sabes, pero cuando >> no, te pegas de leches con los try except... >> >> El lun., 5 jul. 2021 22:41, Federico Mon escribió: >> >>> Yo he usado Celery (poco) y Redis Queue (algo más) y me quedo con este >>> último. >>> >>> En general, no tengo la experiencia de que se mueran los workers. Los >>> trabajos pueden fallar, si salta alguna excepción, etc, pero con un Sentry >>> o similar puedes estar al tanto. >>> >>> Creo que en tu caso sería levantar tantos workers como cores tengas, y >>> así no te excedes con los trabajos simultáneos. Quizás meterlo bajo un >>> supervisor para asegurarte de que no mueren? >>> >>> On July 5, 2021 9:30:25 PM GMT+02:00, Felipe Maza >>> wrote: >>>> >>>> Hola, >>>> >>>> Llevo unos días viendo diferentes programas para gestionar sistemas de >>>> colas y, en principio, creo que casi todos parecen complejos para lo que >>>> necesito. >>>> >>>> Mi problema a resolver es el siguiente, tenemos un modelo de predicción >>>> que se ejecuta periódicamente y también bajo demanda del usuario. Ese >>>> modelo se ejecuta en un solo hilo y tarda bastantes minutos en completar la >>>> tarea. Por tanto, puedo tener varias ejecuciones simultáneas siempre que no >>>> excedamos el número de cores disponibles, ya que en ese caso se vuelve el >>>> sistema excesivamente lento. Al modelo se le invoca a través de una pequeña >>>> api hecha con flask. En el futuro puede que haya otros modelos en la >>>> misma máquina. >>>> >>>> Hace un par de años para un problema similar ya me programé mi propio >>>> gestor de colas rudimentario,pero ahora busco algo que sea estable, con >>>> pocos bugs, mantenible, etc. >>>> >>>> Las características que (creo que) necesito son: >>>> - Encolar tareas (logicamente) >>>> - Tener colas con diferente prioridad (manuales, periódicas). >>>> - Registrar la salida, tanto si ha tenido éxito como si ha tenido >>>> errores. >>>> - (opcional) En un futuro ejecutar otras apis con modelo en la misma >>>> máquina. >>>> >>>> >>>> Lo primero que he explorado ha sido Celery, y es impresionante el >>>> montón de posibilidades que ofrece, tantas que ir poco más de los ejemplos >>>> iniciales me parece muy complejo para solucionar el problema anterior. Me >>>> da la sensación que hay que controlar un montón de aspectos para montarlo y >>>> mantenerlo correctamente; y que cuando aparezca algún error no va a ser >>>> rápido dar con la solución. >>>> >>>> Después de mirar otras alternativas, con la que parece que he montado >>>> una primera versión que parece que me lo soluciona, es Redis Queue ( >>>> https://python-rq.org/). La forma en la que utiliza Redis es >>>> relativamente simple, y más o menos ofrece lo que necesito. >>>> En el tema de los worker creo que ahí flojea un poco, pues parece que >>>> tendré que gestionar manualmente cuántos hay arrancados y si no se han >>>> muerto. >>>> >>>> >>>> ¿Tenéis experiencia resolviendo algún problema similar? ¿Creéis que >>>> merece la pena el esfuerzo para aprender celery (u otra solución) para >>>> algo que no debería ser muy complejo? ¿Redis os parece buen motor o >>>> debería ir a Rabbitmq? Nunca había usado ninguno de ellos. ¿Cómo >>>> gestionais el tema de los worker? Seguro que es más sencillo de lo que >>>> creo. >>>> Cualquier comentario que queráis hacer será bienvenido. >>>> >>>> Gracias, >>>> >>>> Un saludo. >>>> >>> _______________________________________________ >>> Asociación Python España: http://www.es.python.org/ >>> general mailing list >>> general en lists.es.python.org >>> https://lists.es.python.org/listinfo/general >>> >> _______________________________________________ > Asociación Python España: http://www.es.python.org/ > general mailing list > general en lists.es.python.org > https://lists.es.python.org/listinfo/general > ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From virako.9 en gmail.com Tue Jul 13 06:28:33 2021 From: virako.9 en gmail.com (Victor Ramirez) Date: Tue, 13 Jul 2021 12:28:33 +0200 Subject: [Python-es] Tertulia python, martes 13 de Julio a las 21:30 CET Message-ID: Hola, Se convoca la Tertulia de la semana, martes 13 de Julio a las 21:30 CET. Seguimos buscando a alguien con ganas de editar audio, mientras se sigue publicando el excelente trabajo que realizó Pablo en https://podcast.jcea.es/python/ Aclaramos que cuando nos referimos a poca paga, económicamente se refiere a 0 ?, que viene siendo lo que genera el podcast, es un hobby y como tal, pues nos da trabajo que se compensa con mucha satisfacción pero sin dinero. Por lo demás, nada más que animaros a conectaros y participar en estas amenas tertulias, no se requieren conocimientos avanzados, solo ganas de charlar con más gente. Y el texto de siempre: La charla será en la sala "py2021" de jitsi: https://meet.jit.si/py2021 . Se puede entrar con cualquier navegador moderno. También hay aplicaciones para Android e iOS. Bloquearé la sala con clave, que retiraré a las 21:30 para permitir el acceso público. Algunos detalles: - Se grabará el audio de la conversación con vistas a una difusión pública posterior (tipo podcast). Entendemos que los participantes están de acuerdo en ser grabados (el audio, no grabo vídeo). Si alguien tiene pegas con esto lo puede comentar al principio de la tertulia. De todas maneras lo recordaré al empezar. - Se agradece que se entre con vídeo, aunque el sonido esté silenciado, porque hablar a una pantalla llena de recuadros negros resulta confuso y desagradable. No es imprescindible, pero es de agradecer. - A poder ser, ten el sonido silenciado si no estás hablando. Procura que tu audio tenga calidad y no meter ruido ambiente. Procura usar auriculares para evitar el retorno. - La tertulia no tiene tema definido más allá de hablar de Python como lenguaje. Lo más fácil es romper el hielo con algún problema o algún descubrimiento reciente con el que te hayas tropezado con el lenguaje. Sería interesante que trajeras algo pensado. - ¡Trae tu tema! Un saludo. -- Víctor Ramírez de la Corte @virako ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From felipe en felipem.com Tue Jul 13 11:29:42 2021 From: felipe en felipem.com (Felipe Maza) Date: Tue, 13 Jul 2021 17:29:42 +0200 Subject: [Python-es] [Py-ES] Sistemas de colas In-Reply-To: References: <05E1940B-F836-465F-B8E4-7CF931D8A749@gmail.com> Message-ID: Gracias por vuestras respuestas, Por ahora me quedaré con Redis Queue pero sí que habrá que ir viendo poco a poco el tema de celery. Un saludo, El mié, 7 jul 2021 a las 0:30, Nekmo () escribió: > Para nada ha sido pedante o chapas Lasizoillo, es genial contar con > comentarios tan completos y tan bien documentados, ¡gracias! :) > > Nunca me había parado a mirar sobre extender Celery, y ahora ya sé por > dónde empezar. Por curiosidad, ¿para qué habéis tenido la necesidad de > ampliarlo? > > En mi caso uso Celery por los mismos motivos, ya que se adapta a las > necesidades de cualquier proyecto sin necesidad de conocer todos sus > requerimientos. Además, al usarlo en más proyectos, adquiero conocimiento > reaprovechable. Otra ventaja es su robustez, su documentación y añadiría su > monitorización. Es importante monitorizar el correcto funcionamiento de las > colas, y para Celery al ser tan utilizado hay muchos recursos. > > Un cordial saludo: > -- Nekmo. > > Sitio web: http://nekmo.com > Dirección de contacto: contacto en nekmo.com > XMPP/Jabber: contacto en nekmo.com > Google+: Nekmo Com > > > El mar, 6 jul 2021 a las 8:17, Federico Mon () > escribió: > >> Es un buen apunte, yo no he trabajado con procesos que consumiesen tanta >> RAM >> >> On July 5, 2021 11:12:24 PM GMT+02:00, Jose Manuel >> wrote: >>> >>> Quería señalar que si te quedas sin RAM y el trabajo está ya lanzado, si >>> te quedas sin el. >>> >>> Y aunque hagas try, except finally. Al ser matado por el sistema no lo >>> captura ni el try ni sentry. >>> >>> Hablo de creación de ficheros de más de 10GB . >>> >>> Y lo resalto porque bueno, parece obvio cuando ya lo sabes, pero cuando >>> no, te pegas de leches con los try except... >>> >>> El lun., 5 jul. 2021 22:41, Federico Mon escribió: >>> >>>> Yo he usado Celery (poco) y Redis Queue (algo más) y me quedo con este >>>> último. >>>> >>>> En general, no tengo la experiencia de que se mueran los workers. Los >>>> trabajos pueden fallar, si salta alguna excepción, etc, pero con un Sentry >>>> o similar puedes estar al tanto. >>>> >>>> Creo que en tu caso sería levantar tantos workers como cores tengas, y >>>> así no te excedes con los trabajos simultáneos. Quizás meterlo bajo un >>>> supervisor para asegurarte de que no mueren? >>>> >>>> On July 5, 2021 9:30:25 PM GMT+02:00, Felipe Maza >>>> wrote: >>>>> >>>>> Hola, >>>>> >>>>> Llevo unos días viendo diferentes programas para gestionar sistemas de >>>>> colas y, en principio, creo que casi todos parecen complejos para lo que >>>>> necesito. >>>>> >>>>> Mi problema a resolver es el siguiente, tenemos un modelo de >>>>> predicción que se ejecuta periódicamente y también bajo demanda del >>>>> usuario. Ese modelo se ejecuta en un solo hilo y tarda bastantes minutos en >>>>> completar la tarea. Por tanto, puedo tener varias ejecuciones simultáneas >>>>> siempre que no excedamos el número de cores disponibles, ya que en ese caso >>>>> se vuelve el sistema excesivamente lento. Al modelo se le invoca a través >>>>> de una pequeña api hecha con flask. En el futuro puede que haya otros >>>>> modelos en la misma máquina. >>>>> >>>>> Hace un par de años para un problema similar ya me programé mi propio >>>>> gestor de colas rudimentario,pero ahora busco algo que sea estable, con >>>>> pocos bugs, mantenible, etc. >>>>> >>>>> Las características que (creo que) necesito son: >>>>> - Encolar tareas (logicamente) >>>>> - Tener colas con diferente prioridad (manuales, periódicas). >>>>> - Registrar la salida, tanto si ha tenido éxito como si ha tenido >>>>> errores. >>>>> - (opcional) En un futuro ejecutar otras apis con modelo en la misma >>>>> máquina. >>>>> >>>>> >>>>> Lo primero que he explorado ha sido Celery, y es impresionante el >>>>> montón de posibilidades que ofrece, tantas que ir poco más de los ejemplos >>>>> iniciales me parece muy complejo para solucionar el problema anterior. Me >>>>> da la sensación que hay que controlar un montón de aspectos para montarlo y >>>>> mantenerlo correctamente; y que cuando aparezca algún error no va a ser >>>>> rápido dar con la solución. >>>>> >>>>> Después de mirar otras alternativas, con la que parece que he montado >>>>> una primera versión que parece que me lo soluciona, es Redis Queue ( >>>>> https://python-rq.org/). La forma en la que utiliza Redis es >>>>> relativamente simple, y más o menos ofrece lo que necesito. >>>>> En el tema de los worker creo que ahí flojea un poco, pues parece que >>>>> tendré que gestionar manualmente cuántos hay arrancados y si no se han >>>>> muerto. >>>>> >>>>> >>>>> ¿Tenéis experiencia resolviendo algún problema similar? ¿Creéis que >>>>> merece la pena el esfuerzo para aprender celery (u otra solución) >>>>> para algo que no debería ser muy complejo? ¿Redis os parece buen >>>>> motor o debería ir a Rabbitmq? Nunca había usado ninguno de ellos. >>>>> ¿Cómo gestionais el tema de los worker? Seguro que es más sencillo de >>>>> lo que creo. >>>>> Cualquier comentario que queráis hacer será bienvenido. >>>>> >>>>> Gracias, >>>>> >>>>> Un saludo. >>>>> >>>> _______________________________________________ >>>> Asociación Python España: http://www.es.python.org/ >>>> general mailing list >>>> general en lists.es.python.org >>>> https://lists.es.python.org/listinfo/general >>>> >>> _______________________________________________ >> Asociación Python España: http://www.es.python.org/ >> general mailing list >> general en lists.es.python.org >> https://lists.es.python.org/listinfo/general >> > _______________________________________________ > Python-es mailing list > Python-es en python.org > https://mail.python.org/mailman/listinfo/python-es > -- Felipe Maza Fernández felipe en felipem.com 622 338 121 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From virako.9 en gmail.com Mon Jul 19 06:20:29 2021 From: virako.9 en gmail.com (Victor Ramirez) Date: Mon, 19 Jul 2021 12:20:29 +0200 Subject: [Python-es] Tertulia python, martes 20 de Julio a las 23:00 CET [CAMBIO DE HORA] Message-ID: Hola, Se convoca la Tertulia de la semana: ¿Cuándo? *Martes 20 de Julio* a las *23:00 CET*.* IMPORTANTE, CAMBIO DE HORA.* Se ha decidido entre los asistentes asiduos y el grupo de telegram. ¿Dónde? https://meet.jit.si/py2021 Accesible desde cualquier navegador moderno y desde aplicación para Android e iOS. La sala estará bloqueada con clave, que se retirará a la hora de comienzo para permitir el acceso público. ¿Por qué? Porque tenemos ganas de hablar sobre python con más gente. Anímate, no se necesitan conocimientos avanzados, solo ganas de charlar y pasar un buen rato. ANUNCIO: Se busca: Se busca alguien con ganas de editar audio, mientras se sigue publicando el excelente trabajo que realizó Pablo en https://podcast.jcea.es/python/ Se recompensa con mucha satisfacción pero sin dinero. Otros detalles: - Se grabará el audio de la conversación con vistas a una difusión pública posterior (tipo podcast). Entendemos que los participantes están de acuerdo en ser grabados (solo audio, no vídeo). Si alguien tiene pegas con esto lo puede comentar al principio de la tertulia. De todas maneras se recordará al empezar. - Se agradece entrar con vídeo, aunque el sonido esté silenciado, porque hablar a una pantalla llena de recuadros negros resulta confuso y desagradable. No es imprescindible, pero se agradece. - A poder ser, ten el sonido silenciado si no estás hablando. Procura que tu audio tenga calidad y no meter ruido ambiente. Procura usar auriculares para evitar el retorno. - La tertulia no tiene tema definido más allá de hablar de Python como lenguaje. Lo más fácil es romper el hielo con algún problema o algún descubrimiento reciente con el que te hayas tropezado con el lenguaje. Sería interesante que trajeras algo pensado. ¡Trae tu tema! - Al final de la tertulia, recomendamos algo que no tiene porqué estar relacionado con python ni con la informática. Libros, películas, juegos, comidas, deportes, ... ¡Cuéntanos! Un saludo. -- Víctor Ramírez de la Corte @virako ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From garcia.marc en gmail.com Tue Jul 20 14:43:52 2021 From: garcia.marc en gmail.com (Marc Garcia) Date: Tue, 20 Jul 2021 12:43:52 -0600 Subject: [Python-es] =?utf-8?q?Sprint_en_espa=C3=B1ol=3A_pandas_=26_Ibis?= Message-ID: Por si a alguien le interesa aprender a contribuir a proyectos de software libre (o ya sabe y quiere ayudar a otros a contribuir), este jueves vamos a organizar un sprint para contribuir a pandas y a Ibis . Para quien no conozca pandas, es una librería para manipulación y análisis de datos en Python. Ibis es similar a pandas, pero a diferencia de pandas no solo soporta que las computaciones pasen en memoria, sino que pueden delegarse a sistemas de bases de datos (PostgreSQL, MySQL...), al cloud (Spark, Impala...), bases de datos analíticas, y también en memoria (usando el mismo pandas, o pronto usando Arrow). El sprint va a ser online por videollamada, para todos los niveles, y será en español. Empezará a las 16h hora de Ciudad de México (18h hora de Argentina). Para participar, os podéis unir al canal de telegram del sprint (y de otros eventos similares): http://t.me/intro_software_libre [image: ibis_pandas_sprint.png] ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: ------------ próxima parte ------------ Se ha borrado un mensaje adjunto que no está en formato texto plano... Nombre : ibis_pandas_sprint.png Tipo : image/png Tamaño : 270721 bytes Descripción: no disponible Url : From virako.9 en gmail.com Mon Jul 26 06:07:50 2021 From: virako.9 en gmail.com (Victor Ramirez) Date: Mon, 26 Jul 2021 12:07:50 +0200 Subject: [Python-es] Tertulia python, martes 27 de Julio a las 23:00 CET Message-ID: Hola, Se convoca la Tertulia de la semana: ¿Cuándo? *Martes 27 de Julio* a las *23:00 CET*. ¿Dónde? https://meet.jit.si/py2021 Accesible desde cualquier navegador moderno y desde aplicación para Android e iOS. La sala estará bloqueada con clave, que se retirará a la hora de comienzo para permitir el acceso público. ¿Por qué? Porque tenemos ganas de hablar sobre python con más gente. Anímate, no se necesitan conocimientos avanzados, solo ganas de charlar y pasar un buen rato. ANUNCIO: Se busca: Se busca alguien con ganas de editar audio, mientras se sigue publicando el excelente trabajo que realizó Pablo en https://podcast.jcea.es/python/ Se recompensa con mucha satisfacción pero sin dinero. Otros detalles: - Se grabará el audio de la conversación con vistas a una difusión pública posterior (tipo podcast). Entendemos que los participantes están de acuerdo en ser grabados (solo audio, no video). Si alguien tiene pegas con esto lo puede comentar al principio de la tertulia. De todas maneras se recordará al empezar. - Se agradece entrar con vídeo, aunque el sonido esté silenciado, porque hablar a una pantalla llena de recuadros negros resulta confuso y desagradable. No es imprescindible, pero se agradece. - A poder ser, ten el sonido silenciado si no estás hablando. Procura que tu audio tenga calidad y no meter ruido ambiente. Procura usar auriculares para evitar el retorno. - La tertulia no tiene tema definido más allá de hablar de Python como lenguaje. Lo más fácil es romper el hielo con algún problema o algún descubrimiento reciente con el que te hayas tropezado con el lenguaje. Sería interesante que trajeras algo pensado. ¡Trae tu tema! - Al final de la tertulia, recomendamos algo que no tiene porqué estar relacionado con python ni con la informática. Libros, películas, juegos, comidas, deportes, ... ¡Cuéntanos! Un saludo. -- Víctor Ramírez de la Corte @virako ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: