La versión estable de Python 3.15, prevista para el 1° de octubre, sigue sin publicarse tras una tercera candidata de prueba; un nuevo lote de paquetes maliciosos en PyPI suma mineros de criptomonedas y un ladrón de datos; pnpm respalda su rama 11.x con dos correcciones de seguridad; Cloudflare amplía workerd con una API de snapshots para Durable Objects, y uv ya soporta la candidata más reciente de Python antes que el propio lenguaje la convierta en versión final.
El calendario oficial del proyecto fijaba el 1° de octubre para la versión estable 3.15.0; tres días después, el repositorio oficial solo registra una tercera candidata de prueba, sin nueva fecha anunciada.
El registro de etiquetas del repositorio python/cpython en GitHub muestra, revisado la mañana de este domingo 4 de octubre de 2026, que la etiqueta más reciente del proyecto es v3.15.0rc3, publicada el 2 de octubre. El calendario de lanzamiento del proyecto, documentado en el PEP 790 y reflejado en la página oficial de descargas de Python, fijaba el 1° de octubre como fecha de la versión estable 3.15.0; al cierre de esta edición, tres días después de esa fecha, la etiqueta v3.15.0 final no existe ni en el repositorio ni en la lista de lanzamientos. La tercera candidata no estaba en el plan original: el propio equipo de lanzamiento -liderado por Hugo van Kemenade- había presentado la rc2, publicada el 1° de setiembre, como la última candidata antes de la versión final de octubre, según la discusión pública del equipo en discuss.python.org. Que haya aparecido una rc3 el 2 de octubre, un día después de la fecha que debía ser la de la versión estable, indica que el equipo encontró al menos un problema que no quiso dejar pasar hacia producción; el proyecto no ha publicado, en sus canales oficiales, una explicación pública de qué cambió entre la rc2 y la rc3 ni una nueva fecha objetivo. Un atraso de días en un calendario de lanzamiento de software no es inusual, pero rompe la cadencia que el propio PEP 790 prometía. Costa Rica tiene una comunidad amplia de personas desarrolladoras en ciencia de datos, automatización y educación que ya prueba 3.15 en forma de candidata; cualquier equipo tico que haya planificado una migración para el 1° de octubre debe ajustar esa fecha a la espera de que el proyecto confirme cuándo llega la versión final.
El proyecto de código abierto compromised-packages-check documentó, en su reporte del 3 al 4 de octubre de 2026 (PR 147), un total de once entradas nuevas en PyPI, según el registro público del proyecto en GitHub. Ocho de ellas -voxcpmtts3, voxcpmui3, voxcpmeval, voxcpmkit, voxcpmui4, voxcpmintel y voxcpmruntime, entre otras- forman un clúster que imita herramientas de síntesis de voz y despliega un minero de criptomonedas al momento de instalarse; otras tres variantes -voxel-tts, infrabench y caoxiltts- siguen el mismo patrón. Una entrada adicional, echogen 1.0.0, "exfiltra información básica del equipo al instalarse e importarse; sin otro propósito", según la descripción textual del propio registro. El lote de hoy es sustancialmente menor que el de ayer -33 entradas entre npm y PyPI, documentadas en la edición anterior de esta sección- y confirma que el ritmo de hallazgos sigue la misma tendencia a la baja de los últimos días: de 229 casos el 1° de octubre a 33 el día siguiente y a once hoy, aunque esta vez exclusivamente en PyPI, sin entradas nuevas reportadas en npm en este corte. Un clúster de ocho paquetes con un nombre base común que se repite con pequeñas variaciones es una táctica ya documentada esta semana con la familia Baileys en npm: inundar el registro con nombres parecidos para capturar instalaciones por error de tecleo o de búsqueda aproximada. La información de este caso proviene únicamente del registro del proyecto compromised-packages-check en GitHub, sin cobertura cruzada de un medio de seguridad especializado al cierre de esta edición. Costa Rica tiene programadores que instalan paquetes de Python a diario en zonas francas y universidades; revisar el nombre exacto de cualquier herramienta de síntesis de voz antes de instalarla sigue siendo la defensa más simple disponible, sin que se conozca algún caso costarricense afectado por este lote.
El equipo de pnpm publicó, la noche del sábado 3 de octubre de 2026, las versiones 12.9.1 y 11.28.4 del gestor de paquetes de JavaScript, según las notas oficiales de ambas versiones en GitHub. La 11.28.4 -que da mantenimiento a la rama mayor anterior, todavía en uso- corrige dos formas de fuga de credenciales: pnpm login ya no reenvía las credenciales de su solicitud a otro origen durante una redirección, el mismo fallo que esta sección reportó ayer corregido en la rama 12.x con la versión 12.9.0; y el mensaje de error que aparece cuando un paquete descargado falla su verificación de integridad ya no imprime las credenciales, cadenas de consulta ni fragmentos de la URL del paquete, un fallo distinto que no se había corregido antes en ninguna rama. La versión 12.9.1 resuelve, por su parte, un problema de tamaño: mueve el motor de WebAssembly usado dentro de los WebContainers de StackBlitz a un paquete separado, @pnpm/wasm, lo que reduce el paquete principal de pnpm de aproximadamente 55 megabytes a unos 4 megabytes sin empaquetar, según la misma fuente. Que el equipo mantenga correcciones de seguridad simultáneas en dos ramas mayores -12.x y 11.x- muestra cuánta base de usuarios todavía no migra a la versión más reciente apenas semanas después de su salida, y que un fallo de fuga de credenciales en una herramienta usada en integración continua se trata como prioridad en ambas líneas de soporte. La información de este caso proviene únicamente de las notas de versión oficiales de pnpm en GitHub, sin cobertura cruzada de un medio especializado al cierre de esta edición. Costa Rica tiene una comunidad amplia de programadores en zonas francas y startups que usan pnpm para manejar monorepos de JavaScript; quienes todavía corren la rama 11.x por compatibilidad reciben hoy la misma protección que la rama 12.x recibió ayer, sin que se conozca una cifra de cuántos proyectos ticos siguen en esa rama.
cat /feed/cloudflareworkersworkerd.md
La versión v1.20261004.1, publicada a la 01:40 UTC de este domingo, agrega una única función aportada por un colaborador externo: capturar el estado de almacenamiento de un Durable Object en un punto específico.
> Cloudflare publicó, a la 01:40 UTC de este domingo 4 de octubre de 2026, la versión v1.20261004.1 de workerd, el motor de ejecución de código abierto detrás de Cloudflare Workers, según el registro oficial de versiones del proyecto en GitHub. La entrega expone una API de snapshots para Durable Objects -el mecanismo de almacenamiento con estado de Workers-, aportada en una sola contribución por el colaborador externo maxmcd, según el mismo registro. La nota de versión no detalla, por ahora, qué casos de uso recomienda la API ni si la función llega habilitada por defecto en todos los planes de Cloudflare Workers.
> Es la cuarta entrega consecutiva que esta sección documenta en la racha casi diaria de workerd: la versión del 2 de octubre agregó el método ctx.cache.invalidate() para borrar una entrada de caché desde código, y la del 3 de octubre amplió las pruebas de reintento de JSRPC. A diferencia de esas dos, la de hoy llega de un colaborador externo al equipo de Cloudflare, no del propio equipo del producto, lo que sugiere que la comunidad de código abierto alrededor de workerd ya propone capacidades nuevas y no solo reporta fallos.
> La información de este caso proviene únicamente del registro oficial de versiones de workerd en GitHub, sin cobertura cruzada de un medio especializado al cierre de esta edición. Costa Rica no aloja una región de Cloudflare, pero agencias digitales y startups ticas que despliegan aplicaciones sobre Workers reciben la nueva API de forma automática en su próximo despliegue, sin que se conozca todavía un caso de uso local documentado.
Astral publicó, el sábado 3 de octubre de 2026, la versión 0.12.23 de uv, su gestor de paquetes y proyectos de Python escrito en Rust, según las notas oficiales de la versión en GitHub. La entrega agrega soporte para la versión candidata de Python 3.15.0rc3 -publicada por el propio equipo de Python un día antes-, introduce en fase preliminar la posibilidad de sincronizar, exportar e inspeccionar árboles de dependencias a partir de un archivo uv.lock sin necesidad de un manifiesto de workspace, corrige un rechazo indebido de fuentes alternas para miembros de workspace y arregla la compatibilidad del intérprete en Windows ARM64. Que uv ya soporte una candidata de prueba de Python 3.15 -no la versión final, que según el calendario oficial del proyecto debía publicarse el 1° de octubre, como reporta esta misma edición- muestra que el ecosistema de herramientas de terceros alrededor de Python avanza más rápido que el propio calendario de lanzamiento del lenguaje: quien use uv puede empezar a probar su código con la rc3 antes de que exista una versión estable con la que compararla. La información de este caso proviene únicamente de las notas de versión oficiales de uv en GitHub, sin cobertura cruzada de un medio especializado al cierre de esta edición. Costa Rica tiene una comunidad creciente de programadores Python en ciencia de datos, automatización y backend dentro de zonas francas y startups locales; quienes ya migraron su flujo de trabajo a uv reciben esta actualización al correr uv self update, sin que se conozca todavía una cifra de adopción local de la herramienta.
— La versión 0.12.23, publicada el sábado por Astral, suma la recién publicada 3.15.0rc3 a su catálogo de intérpretes y estrena, en fase preliminar, la posibilidad de inspeccionar árboles de dependencias sin un manifiesto de workspace.
La jornada del 4 de octubre de 2026 en desarrollo estuvo marcada por un calendario que no se cumplió: la versión estable de Python 3.15, prevista para el 1° de octubre según el PEP 790, sigue sin aparecer tres días después, con una tercera candidata de prueba -no planeada originalmente- como única novedad desde el repositorio oficial. En cadena de suministro, compromised-packages-check documentó once paquetes maliciosos nuevos en PyPI entre el 3 y el 4 de octubre -un clúster que imita herramientas de síntesis de voz para instalar un minero de criptomonedas y un paquete que solo roba datos básicos del equipo-, continuando la tendencia a la baja de los últimos días: de 229 casos el 1° de octubre a 33 el día siguiente y a once hoy. En herramientas, pnpm cerró dos fugas de credenciales distintas repartidas entre sus ramas 12.x y 11.x, Cloudflare sumó una API de snapshots para Durable Objects a workerd en su cuarta entrega consecutiva de la semana, y uv ya soporta la candidata más reciente de Python 3.15 pese a que la propia versión final del lenguaje todavía no existe. Todas las historias completas, con sus fuentes primarias, quedan disponibles arriba para decidir qué actualizar, revisar o parchar primero esta semana.