Cambiar un gran sistema de datos en Python sin romper la ejecución diferida

## Seguir el comportamiento pedido hasta la capa que lo gestiona Antes de cambiar un código base grande de datos en Python o de computación paralela, crea un mapa específico para la tarea en vez de leer el repositorio de forma indiscriminada. Identifica las capas implicadas: 1. Colecciones públicas o interfaces dirigidas al usuario. 2. Expresiones simbólicas o grafos de alto nivel utilizados para la planificación y la optimización. 3. Tareas materializadas de bajo nivel y aristas de dependencia. 4. Planificadores o motores de ejecución. 5. Capas de configuración, despacho, serialización y utilidades. Sigue el comportamiento solicitado desde el punto de entrada público hasta la capa de implementación más pequeña que lo controla. Lee las pruebas y la configuración cercanas antes de editar. Navega según la tarea: - Comportamiento de planificación: API públicas de cálculo, utilidades de grafos, representaciones de tareas y, después, adaptadores del planificador. - Optimización de grafos: protocolos de grafos de alto nivel, capas por bloques o de expresiones y, después, materialización. - Funciones de arrays o marcos de datos: API de colección, implementación de la operación, despacho y, después, pruebas enfocadas. - Cambios de configuración: accesores de ejecución, configuración predeterminada, esquema y documentación. - Compatibilidad con motores: interfaz del motor, registro de puntos de entrada, despacho y pruebas de compatibilidad. Trata los nombres de módulos, los recuentos de líneas y las versiones de dependencias indicados en las notas del repositorio como pistas de navegación, no como hechos permanentes. Confirma localmente el código fuente y los manifiestos actuales. Mantén explícitos los límites de los subsistemas. Un cambio en una colección pública puede requerir actualizaciones correspondientes de metadatos, grafos, planificadores, pruebas y documentación, pero no edites capas no relacionadas. ## Usar los entornos del repositorio y elegir el alcance de pruebas más pequeño Usa el gestor de entornos y los comandos declarados por el repositorio. No supongas que una instalación global de Python coincide con las combinaciones de dependencias compatibles. Antes de implementar: 1. Examina el manifiesto del proyecto y los entornos disponibles. 2. Selecciona el entorno más pequeño que represente la función afectada. 3. Localiza las pruebas, los recursos de prueba, los marcadores y las funciones de aserción existentes más cercanos. 4. Registra las dependencias opcionales, los indicadores de función y las políticas de advertencias pertinentes. Prefiere los envoltorios de comandos proporcionados por el repositorio para: - una sola prueba fallida; - el archivo de pruebas del módulo afectado; - el análisis de código y las comprobaciones estáticas; - las pruebas de documentación de ejemplos públicos; - los entornos de dependencias mínimas o funciones opcionales; - comprobaciones más amplias equivalentes a la integración continua solo cuando el cambio las justifique. Respeta el comportamiento estricto de las pruebas, como tratar las advertencias como errores, los fallos esperados estrictos, los tiempos de espera y los marcadores específicos del entorno. Usa las funciones compartidas de igualdad para colecciones diferidas cuando tengan en cuenta metadatos, tipos, particiones o tolerancia numérica. Para dependencias opcionales, usa las funciones del proyecto para importar y omitir pruebas en vez de condiciones improvisadas. Ten presentes las versiones mínima y más reciente compatibles al utilizar API nuevas. No instales paquetes, cambies entornos ni habilites pruebas dependientes de la red a menos que la tarea lo autorice. Informa de una dependencia ausente como una limitación del entorno en vez de modificar la máquina silenciosamente. ## Mantener la ejecución diferida: no llamar a `compute()` al construir grafos Conserva la invariante central de los sistemas de grafos diferidos: el código que construye el grafo debe describir el cálculo sin ejecutarlo. No llames nunca a métodos de materialización inmediata como `compute()` o `persist()` al definir operaciones de colección, capas de grafos o expresiones simbólicas. La materialización corresponde a un límite explícito del usuario o de ejecución. Durante la construcción del grafo: - infiere los resultados a partir de los metadatos siempre que sea posible; - mantén las dependencias de las tareas explícitas y deterministas; - conserva claves estables y el comportamiento de tokenización; - evita operaciones de entrada o salida ocultas y la selección implícita del planificador; - mantén separadas la optimización simbólica y la ejecución de bajo nivel. Sigue las convenciones del repositorio: - añade anotaciones de tipo completas al código nuevo; - mantén coherentes los imports de compatibilidad y las anotaciones diferidas; - usa imports protegidos solo para tipos a fin de evitar ciclos; - organiza de forma predecible los imports de la biblioteca estándar, de terceros y locales; - usa el estilo de cadenas de documentación establecido y ejemplos ejecutables para las API públicas; - sigue las convenciones de nombres existentes para funciones auxiliares privadas, pruebas y funciones de despacho. Al añadir un motor, una expresión, una capa o una opción de configuración, actualiza todos los puntos de registro necesarios y añade una prueba enfocada que demuestre que el despacho o la planificación alcanza la nueva implementación. Los indicadores de función que afecten al registro durante la importación o a la planificación de consultas deben establecerse antes de importar por primera vez el módulo correspondiente. Prueba el comportamiento habilitado y deshabilitado cuando ambos sigan siendo compatibles. Evita las refactorizaciones amplias al reparar un defecto de alcance limitado. Conserva el comportamiento no relacionado y realiza el cambio mínimo que explique el nuevo resultado de la prueba. ## Ampliar las pruebas paso a paso y no publicar nada sin permiso Verifica con un alcance creciente: 1. Reproduce el fallo anterior con una prueba enfocada. 2. Ejecuta el archivo de pruebas o el conjunto del subsistema más cercano. 3. Ejecuta las comprobaciones de código, tipos o documentación afectadas directamente por la edición. 4. Ejercita las variantes pertinentes de funciones opcionales, dependencias mínimas o indicadores de función. 5. Usa el conjunto completo solo cuando el cambio cruce límites arquitectónicos amplios. Comprueba los modos de fallo habituales: - ciclos de importación y orden de registro; - indicadores de función modificados después de la primera importación; - metadatos que no concuerdan con los resultados calculados; - paquetes opcionales no disponibles en algunos intérpretes; - versiones fijadas de dependencias que se desalinean entre paquetes relacionados; - valores predeterminados de configuración ausentes del esquema; - ejemplos de pruebas de documentación que ya no se ejecutan; - pruebas que solo pasan con un planificador o motor. Antes de informar de que el trabajo está completo, revisa las diferencias e indica qué comprobaciones se ejecutaron realmente, cuáles pasaron y cuáles no se ejecutaron. No deduzcas el éxito únicamente de la inspección del código. El trabajo de publicación pertenece a un límite de autoridad independiente. Nunca crees un lanzamiento, publiques paquetes, envíes etiquetas, cargues artefactos ni modifiques sistemas externos de publicación sin autorización explícita. Si se autoriza la preparación de una publicación, verifica las entradas del registro de cambios, las versiones y restricciones de versión entre paquetes, los artefactos de empaquetado y la secuencia documentada por el repositorio antes de modificar cualquier estado externo. Cuando se te pida comunicarte con otras personas, presenta pruebas y opciones sin suplantar al usuario ni inventar sus decisiones.