Dynamo o Python para Revit: elige por el problema, no por la moda
El estudio quería automatizar la numeración de puertas. La primera propuesta fue hacerla en Python porque «sería más profesional». La segunda defendía Dynamo porque el equipo ya lo conocía. Mientras discutían lenguajes, nadie había aclarado qué ocurría con puertas de aseos, viviendas repetidas, fases, grupos, números reservados o cambios después de emitir planos. La tecnología estaba lista; el problema aún no.
Elegir Dynamo o Python para Revit no es escoger entre principiante y experto. Es decidir cómo representar la lógica, cuánto acceso necesitas, quién mantendrá la solución y qué riesgo tiene modificar el modelo. En muchas automatizaciones ambos pueden convivir. En otras, ninguna es la respuesta adecuada hasta ordenar el proceso.
Tabla de contenidos
La numeración parecía una secuencia hasta que apareció el proyecto
Sobre una planta sencilla, bastaba con ordenar puertas por habitación y asignar números. En el edificio real había puertas que servían a dos espacios, elementos dentro de grupos, unidades repetidas y huecos provisionales. Algunas numeraciones debían conservarse aunque cambiase la geometría. Otras dependían de un código de vivienda mantenido en otra tabla.
El equipo escribió ejemplos correctos y conflictivos. Definió qué puerta entraba, cómo obtenía su ámbito, qué claves formaban el número y quién resolvía una ambigüedad. También estableció que el primer flujo solo propondría números y detectaría duplicados. Escribir llegaría después.
Esta preparación redujo la comparación tecnológica a preguntas concretas: había que leer elementos, relacionarlos con habitaciones, aplicar reglas, mostrar propuestas y, tras confirmación, escribir un parámetro. El volumen era moderado, el equipo BIM necesitaba entender la lógica y las excepciones seguían evolucionando.
Dynamo hizo visible una regla que todavía estaba aprendiendo
El primer prototipo se construyó en Dynamo. Los responsables podían seguir selección, filtrado, asociación con espacios y construcción del código. Al revisar el grafo aparecieron decisiones erróneas: ordenar por coordenada no conservaba números y una puerta entre dos habitaciones no tenía un único «From Room» útil en todos los casos.
Modificar el flujo durante la conversación resultaba rápido. Los nodos permitían enseñar datos intermedios y comparar alternativas. Para un problema aún inestable, esa visibilidad valía más que una implementación compacta.
Dynamo también acercaba la herramienta a usuarios que no programaban en texto. Eso no eliminaba la necesidad de diseño, pero distribuía la comprensión. Un grafo claro podía actuar como documento ejecutable mientras las reglas maduraban.
La complejidad no se midió contando nodos
El prototipo creció al añadir fases, grupos y estados. Parte del tamaño procedía de decisiones reales; otra, de repetir operaciones y gestionar listas. El equipo no concluyó automáticamente que debía «pasar a Python». Primero reorganizó etapas, encapsuló funciones y separó configuración.
Una lógica visual grande puede seguir siendo mantenible si sus bloques tienen contratos claros. Un script corto puede ser opaco si mezcla lectura, reglas y escritura. La complejidad relevante es cuánto conocimiento necesitas para predecir el resultado y modificarlo sin romper otra parte.
Cuando varias reglas necesitaban pruebas con muchos casos, el coste de inspeccionarlas dentro del grafo aumentó. Ahí Python empezó a aportar una ventaja: representar registros, funciones y resultados de forma más estructurada, sin depender de Revit para cada prueba.
Python entró como una pieza, no como una mudanza
El equipo mantuvo Dynamo como orquestación y vista previa. Un nodo Python recibió datos normalizados de las puertas y devolvió propuestas, avisos y bloqueos. No abría transacciones. Su trabajo era aplicar reglas deterministas y explicar el resultado.
Las funciones podían probarse con casos: puerta normal, entre dos espacios, sin habitación, dentro de grupo o con número reservado. Cada caso tenía una salida esperada. Corregir una regla no exigía navegar por varias ramas visuales.
Esta combinación permitió evolucionar sin expulsar al equipo BIM del proceso. Dynamo mostraba entradas y etapas; Python concentraba lógica que se beneficiaba de tipos, funciones y pruebas. La frontera era más importante que la pureza tecnológica.
El acceso a la API cambió la decisión en otras tareas
La numeración utilizaba operaciones accesibles desde ambos entornos. Sin embargo, algunas automatizaciones necesitaban eventos de Revit, interfaces integradas, procesos en segundo plano o control detallado de documentos. En esos casos, un complemento sobre la API podía ser más adecuado que un grafo lanzado manualmente.
Python dentro de Dynamo seguía ejecutándose en el contexto y motor disponibles. Las bibliotecas, compatibilidad y acceso a determinadas APIs dependían de versión y entorno. No era «Python sin límites». El equipo debía conocer motor, dependencias y forma de distribución.
Si la herramienta tenía muchos usuarios, permisos distintos y alto impacto, la comparación dejaba de ser solo Dynamo frente a Python. Entraban empaquetado, interfaz, soporte, telemetría y ciclo de versiones. A veces la solución correcta era una aplicación mantenida; otras, un grafo controlado bastaba.
La vista previa pesó más que el lenguaje
Antes de escribir números, el sistema mostraba puerta, ámbito, valor existente, propuesta y motivo. Los duplicados y ambigüedades se bloqueaban. El usuario podía corregir datos o aceptar excepciones autorizadas.
Esta capacidad determinó la seguridad mucho más que usar nodos o texto. Un script Python que modifica cien puertas sin vista previa es menos controlable que un grafo bien diseñado. Un grafo que escribe al cargar tampoco gana puntos por ser visual.
Después de confirmar, la capa de ejecución abría una transacción y registraba resultados. Volvía a leer el parámetro para verificar. Las puertas de grupos o no editables aparecían como fallos localizados, no como una ejecución completamente verde.
El mantenimiento tuvo voz en la elección
El estudio tenía varias personas capaces de leer Dynamo y una que dominaba Python. Eso favorecía mantener la interfaz y reglas simples en el grafo, pero hacía arriesgado concentrar todo en un módulo que solo una persona podía tocar. Se acordaron revisión, documentación y formación antes de ampliar código.
Las convenciones de numeración cambiaban por proyecto, así que vivían en configuración. La lógica común tenía versión y pruebas. Los paquetes de Dynamo y el motor de Python se declaraban. Actualizar Revit activaba una comprobación sobre modelos conocidos.
El coste no era únicamente aprender sintaxis. Incluía comprender la API, preparar datos, probar, distribuir y atender fallos. Dynamo reducía barrera visual en algunos equipos; Python facilitaba ingeniería de reglas. Ambos podían producir deuda técnica con sorprendente igualdad de oportunidades.
Una matriz útil empezó por el estado del problema
| Criterio | Dynamo suele encajar | Python suele aportar más |
|---|---|---|
| Reglas aún en exploración | La lógica visual facilita revisarla con el equipo | Puede esperar hasta estabilizar casos |
| Transformación de datos compleja | Viable si el flujo conserva claridad | Funciones y pruebas ayudan a estructurarla |
| Acceso a API | Bueno para operaciones cubiertas por nodos y contexto | Útil para control específico, según motor y host |
| Usuarios mantenedores | Adecuado si el equipo domina grafos | Adecuado si existe capacidad de código y revisión |
| Distribución y alto impacto | Requiere control de paquetes y versiones | Puede exigir empaquetado o evolucionar a complemento |
La tabla no elegía por sí sola. Ayudaba a discutir la automatización concreta. Un mismo estudio podía prototipar en Dynamo, consolidar reglas en Python y más tarde empaquetar una herramienta, sin que cada paso invalidase el anterior.
Los anti-ejemplos aclararon más que la moda
Usar Python para sumar dos parámetros no aportaba valor si escondía una lógica que el equipo podía mantener visualmente. Construir un grafo de cientos de nodos para gestionar estructuras complejas tampoco era una defensa razonable de Dynamo.
La IA no resolvía la elección. Podía ayudar a explicar código o proponer un fragmento, pero no conocía automáticamente convenciones, versiones ni consecuencias sobre el modelo. El resultado requería revisión y pruebas. Generar más rápido una automatización equivocada seguía siendo equivocarse.
También había tareas que no debían automatizarse todavía. Si la numeración cambiaba en cada reunión o nadie asumía el criterio, convenía estabilizarla. Se podía detectar duplicados sin asignar nuevos valores. Una ayuda parcial ofrecía control sin congelar decisiones abiertas.
El equipo eligió una arquitectura, no un ganador
La solución final utilizó Dynamo para seleccionar configuración, leer el modelo y presentar resultados; Python para evaluar reglas; y una capa determinista para aplicar cambios confirmados. Cuando las reglas se estabilizaron y el uso creció, el estudio revisó si merecía empaquetarla como complemento.
La elección podía haber sido distinta en otro equipo. Una persona con buen dominio de Python y pruebas quizá habría construido una herramienta textual desde el inicio. Un flujo pequeño y transparente podía permanecer enteramente en Dynamo. El criterio era coste total y capacidad de control.
Para decidir entre Dynamo o Python en Revit, define primero el problema, su riesgo y sus mantenedores. Prototipa donde la lógica se pueda discutir, mueve a código lo que necesite estructura y no abras una transacción hasta saber cómo verificarla.
Si la discusión sigue girando alrededor de qué herramienta parece más profesional, vuelve a las puertas. Ellas no tienen preferencias tecnológicas; solo una notable capacidad para estar en dos habitaciones cuando menos conviene.
Respuestas