Python para Revit: de Dynamo a reglas comprobables

El grafo empezó buscando espacios sin código. Cada excepción añadió una rama hasta que explicar una salida pasó a requerir tres pantallas y la presencia del autor. Sigue ahorrando clics, sí; también ha creado un pequeño monopolio sobre su interpretación. Python puede ayudar a separar reglas y comprobarlas, pero cambiar cables por un bloque de código incomprensible no es una mejora por decreto. Vamos a sacar la lógica del escondite antes de elegirle otro envoltorio.

Python para Revit puede ayudar a reunir esa lógica, siempre que sepamos qué parte queremos mover. Seguiremos un ejemplo hipotético de control de códigos de espacios: Dynamo recoge y presenta, una función clasifica propuestas y una capa de integración aplica únicamente los cambios revisados. La decisión interesante está en esa separación. Esconder el grafo entero dentro de un nodo Python solo conseguiría que el misterio ocupase menos pantalla.

Primero identifica la decisión que se ha vuelto difícil de leer

La distinción inicial entre «código vacío» y «código informado» pronto resulta insuficiente. Un espacio puede tener el valor esperado, contener otro distinto, carecer de propuesta o estar fuera de la fase acordada. También puede faltar el parámetro o no ser editable el elemento. Si todos esos casos se reducen a una salida vacía, quien usa el flujo pierde precisamente la información necesaria para decidir qué hacer después.

Dales estados que describan situaciones diferentes. «Sin cambios» significa que el dato coincide; «actualizar» propone completar un valor; «conflicto» señala una discrepancia que requiere criterio; «omitido» explica una exclusión de alcance; «no evaluable» reconoce que falta información necesaria. Esta clasificación permite separar una decisión BIM de un fallo técnico. Que un espacio no pueda evaluarse no demuestra que esté mal, del mismo modo que no recibir incidencias no demuestra que todo cumpla.

En el ejemplo, una política prudente podría completar códigos vacíos y conservar cualquier valor existente que difiera de la propuesta hasta que alguien lo revise. Otro proyecto podría necesitar una actualización más amplia, pero tendría que decirlo. El lenguaje no decide esa política. Un script que sobrescribe correctamente lo que nunca debía sobrescribir puede ser impecable en sintaxis y bastante perjudicial en sus efectos.

La pieza candidata a pasar a Python sería la clasificación de cada solicitud. Recibiría datos simples ya leídos y devolvería un resultado comprensible. Dynamo podría mantener las entradas y la tabla de revisión. Así cambias una responsabilidad concreta y conservas un recorrido que el equipo reconoce. Si no puedes explicar qué mejora al mover esa parte, reorganizar el grafo o unificar la configuración quizá sea suficiente.

Esta separación también facilita el soporte. Cuando aparece un código inesperado, puedes preguntar si se leyó mal el modelo, si la propuesta de la hoja era incorrecta o si la regla clasificó mal unos datos correctos. Son problemas distintos y necesitan comprobaciones distintas. Mezclarlos en una única función que consulta, interpreta y escribe convierte cada incidencia en una excursión por todas las capas de la herramienta.

Revit y Dynamo representan el mismo elemento de formas distintas

Python es el lenguaje; el entorno que lo ejecuta proporciona motor, bibliotecas y acceso al documento. Un fragmento preparado para Dynamo no se puede trasladar sin más a cualquier consola instalada en Windows. La guía Python and Revit de Dynamo muestra referencias a bibliotecas y servicios del anfitrión para trabajar con el documento. Esas líneas responden a un contexto concreto, no a un ritual de importaciones que haga aparecer Revit en cualquier sitio.

Dynamo utiliza envoltorios para representar elementos en sus nodos, mientras la API trabaja con sus propias clases. Según el origen de la entrada, el código puede necesitar recuperar el elemento interno antes de utilizar determinadas operaciones. Conviene inspeccionar el tipo recibido y reducir la primera consulta a algo sencillo, como identificación y nombre. Una excepción de atributo puede indicar que estás hablando con otra representación del objeto, no que el espacio haya dejado de existir por desacuerdo con Python.

También hay que comprobar la forma de las colecciones. Si Dynamo entrega espacios agrupados por nivel y el script espera una lista plana, aplanar todo puede eliminar una relación que el informe necesita conservar. Decide si la agrupación seguirá formando parte de la estructura o si el nivel se incorporará explícitamente a cada registro. Hacer desaparecer una excepción no equivale a conservar el significado de los datos; los filtros tienen esa delicada habilidad para dejarnos una salida limpia y una explicación incompleta.

La lectura del parámetro necesita distinguir presencia, tipo y valor. Un parámetro inexistente requiere una respuesta distinta de otro que existe y está vacío. Una diferencia de plantilla puede exigir adaptar la configuración antes de proponer nada. Si conviertes ambos casos en la cadena vacía, la regla podría marcar como actualizable algo que la integración ni siquiera sabe dónde escribir. El diagnóstico debería conservar el identificador y explicar qué comprobación no pudo hacerse.

Por último, establece el alcance documental. Un elemento procedente de un vínculo puede servir como contexto de lectura, pero no debe tratarse como si perteneciese al documento activo y fuese editable allí. Identificación, documento de origen y fase forman parte de la consulta. Son detalles menos vistosos que el primer cambio masivo de parámetros, aunque suelen determinar si ese cambio es una herramienta o un incidente pendiente de fecha.

Una función de clasificación se puede probar fuera del modelo

Una vez leídos los datos, la regla puede trabajar con cadenas normalizadas y estados explícitos. En el fragmento, «actual» es una cadena y la existencia del parámetro se comunica por separado. «Propuesto» puede ser una cadena o ausencia de propuesta. Recortar espacios exteriores evita diferencias accidentales; convertir mayúsculas, sinónimos o códigos de cliente requiere una política adicional. No conviene normalizar tanto que terminemos cambiando el significado de un identificador.

El orden de las comprobaciones expresa prioridades. Primero se excluye lo que queda fuera de alcance; después se rechazan datos que no permiten evaluar o completar el código. Una propuesta vacía no autoriza a borrar el valor existente. Cuando hay coincidencia no hace falta modificar; cuando hay discrepancia con un valor ya informado aparece un conflicto. Solo un código vacío con propuesta válida y permiso de edición termina como candidato a actualizar.

La función no consulta el modelo ni afirma que una escritura haya ocurrido. Tampoco detecta duplicados entre varios espacios: eso exige validar el conjunto de propuestas antes de aplicar cambios. Este límite permite entender qué demuestra una prueba de la función y qué seguirá pendiente en la integración. El ejemplo acepta los tipos descritos; la lectura de Excel debe validarlos antes de llamarlo.

				
					# Clasifica valores normalizados; no modifica el modelo.
def decidir_codigo(actual, propuesto, incluido=True,
                   editable=True, parametro_existe=True):
    if not incluido:
        return {"estado": "omitido", "motivo": "fuera de alcance"}
    if not parametro_existe:
        return {"estado": "no_evaluable", "motivo": "falta parametro"}
    if propuesto is None or not propuesto.strip():
        return {"estado": "no_evaluable", "motivo": "sin propuesta"}

    actual = actual.strip()
    propuesto = propuesto.strip()

    if actual == propuesto:
        return {"estado": "sin_cambios"}
    if actual:
        return {"estado": "conflicto",
                "actual": actual, "propuesto": propuesto}
    if not editable:
        return {"estado": "omitido", "motivo": "no editable"}
    return {"estado": "actualizar", "valor": propuesto}

La propuesta y la escritura necesitan comprobaciones diferentes

El recorrido completo empezaría leyendo espacios y hoja, validando columnas y conservando referencias. Después se construiría una tabla con documento, elemento, nivel, código actual, propuesta, estado y motivo. Hasta ahí podemos revisar la calidad de la entrada y la aplicación de la regla sin modificar el modelo. Una tabla útil permite localizar el caso en Revit; un conjunto de mensajes genéricos obliga al operador a investigar el problema desde cero.

Antes de ofrecer una confirmación hay que comprobar relaciones que la función individual no conoce. Dos espacios podrían recibir el mismo código, una fila podría apuntar a un elemento inexistente o varias filas discrepar sobre el mismo destino. También debe quedar claro cómo se selecciona el subconjunto que se aplicará. «Actualizar» expresa una propuesta de la regla, no una autorización suficiente para ejecutar sin revisión.

Las modificaciones de Revit requieren una transacción válida. La referencia de Transaction de Autodesk explica sus restricciones, incluidas las limitaciones de documentos de solo lectura y vinculados. La implementación debe respetar además la gestión de transacciones del entorno que aloja Python. Copiar la apertura de una transacción desde otro contexto puede crear un problema nuevo donde pretendíamos introducir control.

Entre preparar la propuesta y escribir pueden cambiar el documento o el valor del parámetro. Vuelve a comprobar las condiciones críticas y define cómo responder al fallo: cancelar el lote o admitir resultados parciales puede tener sentido según la coherencia que necesite el trabajo. El usuario debe conocer esa política y recibir un resultado fiel. Capturar cualquier excepción y devolver «completado» ofrece una interfaz muy serena a costa de dejar de contar lo que pasa.

Al terminar, comprueba los valores afectados y distingue lo aplicado de lo pendiente. Conserva la referencia de la regla y los datos necesarios para interpretar la ejecución, evitando informes que atribuyan éxito a una simple intención de escritura. Una prueba local de clasificación no demuestra esta integración; necesitaría un modelo controlado y contrastar sus efectos. Esa diferencia permite avanzar por etapas sin adjudicar al prototipo resultados que todavía no ha acreditado.

Mantén la herramienta dentro de lo que el equipo puede sostener

La primera revisión debería incluir código vacío, valor coincidente, conflicto, propuesta ausente, parámetro inexistente y elemento no editable. Comprueba además qué sucede al repetir sin cambios y al alterar la entrada después de preparar la vista previa. Algunos casos pueden validarse con la función; otros requieren el entorno real. Mantenerlos separados ayuda a localizar una regresión cuando cambia la lógica o cuando actualizas la integración.

La distribución necesita indicar versiones de Revit, Dynamo, motor Python y dependencias utilizadas. «Funciona con Python» es una descripción de compatibilidad aproximadamente tan útil como «necesita electricidad». Si el destinatario tiene que reconstruir el entorno por ensayo y error, el esfuerzo no desaparece del proyecto: se desplaza a alguien que probablemente dispone de menos información que el autor.

Una interfaz nueva o un complemento pueden resultar adecuados cuando el uso se estabiliza y crece, pero añaden instalación, soporte y decisiones de producto. Para un flujo que sigue evolucionando junto al equipo, mantener Dynamo como entrada y revisión puede ser razonable. También puede desaparecer la necesidad si se corrige la plantilla o cambia el intercambio. Retirar una automatización que ya no compensa es una forma bastante saludable de mantenimiento.

El objetivo es que el flujo vuelva a contar una historia legible: recibe datos, explica propuestas y modifica lo confirmado bajo condiciones comprobadas. Python aporta valor cuando facilita entender y probar una parte que se había vuelto opaca. Si tu grafo sigue claro y mantenible, puedes dejarlo tranquilo; el código no cobra prestigio por expulsar nodos.

La parte que merece pasar a Python es la que puedes describir, separar y poner a prueba. Conserva Dynamo donde haga visible el recorrido y exige al código resultados interpretables. Si para corregir una regla debes adivinar qué significa una variable compartida por todo el script, has trasladado el misterio de pantalla. El lenguaje habrá cambiado; el problema mantiene el contrato.