¿Qué cambia el build free-threaded del PEP 703 para el código que escribes?

El build free-threaded, publicado como intérprete opcional desde CPython 3.13, elimina el GIL para que varios hilos puedan ejecutar bytecode de Python en paralelo. Tu código pasa a ser realmente concurrente, lo que significa que las condiciones de carrera que el GIL tapaba ahora son reales. Necesitas locks explícitos alrededor del estado mutable compartido, y tienes que comprobar que todas las extensiones en C de las que dependes lo soporten.

El free threading llegó como build experimental en 3.13 y desde entonces ha ido madurando, y la clave es que es un intérprete aparte que eliges usar, no algo que cambió en silencio para todo el mundo. Sin el lock, dos hilos pueden ejecutar bytecode en dos núcleos a la vez, así que un pool de workers con carga de CPU por fin escala sin pagar el arranque de procesos ni el coste de serializar. Lo que cambias a cambio es corrección. Con el build antiguo, mucho código descuidado se libraba de actualizar diccionarios sin sincronizar porque rara vez caía un límite de bytecode en el sitio equivocado. Ahora eso son carreras de datos de verdad y necesitas un Lock o una cola. Lo probé en un job de scoring que repartía trabajo entre cuatro procesos, y con hilos obtuve un rendimiento parecido con mucha menos memoria, porque el modelo se quedaba cargado una vez en lugar de cuatro. Lo que lo bloqueó para producción fueron las extensiones. Todo lo que tiene una capa en C hay que recompilarlo contra la ABI free threaded, así que antes de llevarlo a producción auditaría el árbol de dependencias y miraría qué han publicado los mantenedores.