Dynamo o Python para Revit: cómo elegir con criterio

«En Python es más profesional». Qué alivio: ya podemos elegir la tecnología sin perder tiempo entendiendo la tarea. «Dynamo lo mantiene cualquiera» ofrece un atajo parecido, hasta que aparece un grafo de trescientos nodos y el supuesto cualquiera solicita refuerzos. No voy a arbitrar una competición de prestigio entre lenguajes. Vamos a numerar unas puertas y a ver dónde vive la dificultad: en los datos, en la regla o en el mantenimiento que nadie había incluido en el debate.

Para comparar Dynamo o Python para Revit, vamos a utilizar un caso hipotético de numeración de puertas. Nos permitirá seguir una decisión desde las reglas del proyecto hasta la herramienta que recibe el equipo. El objetivo es elegir una forma de construir, revisar y mantener la automatización que encaje con su uso, sin confundir el lenguaje con un certificado de calidad.

Las puertas no conocen tu debate tecnológico

Numerar puede parecer una operación elemental: recoger puertas, ordenarlas y asignar una secuencia. En un proyecto aparecen preguntas bastante menos dóciles. Hay puertas entre dos habitaciones, accesos exteriores, viviendas repetidas y números que deben conservarse porque ya figuran en una entrega. También puede haber grupos, fases y elementos que no se pueden editar en el momento de la ejecución. Una secuencia de números cabe en una línea; una convención de proyecto necesita algo más de conversación.

Imagina que el código combina planta, vivienda y posición de la puerta. Antes de automatizarlo, habría que acordar cómo se obtiene cada parte, qué identifica de forma estable a la puerta y quién decide cuando dos ámbitos parecen válidos. El orden por coordenadas puede servir para una primera propuesta, pero no garantiza que una numeración emitida sobreviva a un cambio de distribución. Si la regla pretende conservar códigos, «volver a ordenar todo» puede ser precisamente el comportamiento que debemos impedir.

La API ayuda a consultar información, pero no decide qué habitación debe gobernar nuestra convención. La referencia de FromRoom de Autodesk describe esa propiedad para puertas y ventanas, incluido su contexto de fase y los casos en que puede devolver un valor nulo. Convertir una consulta de ese tipo en «la habitación correcta» requiere interpretar el modelo y la regla de negocio. Ahí empieza la automatización; los nombres de las propiedades todavía no la han resuelto.

Un primer alcance razonable sería leer las puertas de un ámbito definido, conservar su identificación, proponer códigos y señalar duplicados o ambigüedades. La escritura podría esperar a que el equipo revisase esa propuesta. Esto permite contrastar el criterio sin convertir cada discusión en una modificación del modelo. Además, una herramienta de diagnóstico puede aportar valor por sí sola si las reglas de numeración todavía cambian entre proyectos.

Escribe unos pocos ejemplos completos antes de comparar entornos: una puerta interior corriente, una entre dos habitaciones, una sin habitación y otra con código que deba conservarse. Define la salida esperada y los casos que necesitan intervención. Ahora sí puedes preguntar qué representación facilita más entender y comprobar esas reglas. Antes estabas eligiendo utensilios con el menú en blanco; una práctica muy extendida, aunque no mejore por ello el resultado.

Dynamo aporta una mesa de trabajo visible

Dynamo resulta especialmente útil cuando sus usuarios pueden seguir cómo una entrada pasa por varias operaciones y produce un resultado. En nuestro caso, separar selección, lectura de habitaciones, construcción de la propuesta y comprobación de duplicados permite discutir cada etapa con el equipo BIM. Al mostrar los datos intermedios puedes descubrir pronto que el ámbito elegido incluye puertas de otra fase o que la convención escrita no contempla un acceso exterior.

Esa visibilidad exige trabajo. Los grupos deben representar responsabilidades, los nombres explicar qué datos circulan y las listas conservar la relación entre cada puerta y su diagnóstico. Si multiplicas filtros y eliminas valores vacíos de listas paralelas sin mantener sus asociaciones, el grafo puede volverse difícil de razonar aunque siga teniendo una apariencia ordenada. Los colores ayudan a orientarse; no convierten automáticamente el cableado en un argumento lógico.

Cuando una parte se repite, un nodo personalizado puede reducir ruido y ofrecer una función reconocible. Pero conviene comprobar qué se gana al ocultarla: si la regla cambia a menudo y el equipo necesita discutirla, quizá deba permanecer visible; si es una operación estable y bien definida, encapsularla puede facilitar el uso. El número de nodos es una pista sobre el esfuerzo de lectura, no una medida suficiente de la calidad del flujo.

Dynamo también tiene un coste de distribución. Los paquetes, sus versiones y el entorno anfitrión forman parte de la herramienta que entregas. Un grafo que depende de una configuración personal difícil de reconstruir puede resultar tan frágil como un script mal empaquetado. La pregunta útil es si el destinatario podrá ejecutar, interpretar y mantener la solución con los recursos del equipo. «No hay código» deja de ser una ventaja cuando lo siguiente que dices es «pero no toques este grupo».

Para el ejemplo, un prototipo visual puede ser una buena primera etapa si ayuda a estabilizar el criterio con quienes lo aplicarán. No necesita convertirse después en otra cosa para justificar su existencia. Si el flujo se mantiene claro, las dependencias están controladas y cumple su función, conservarlo en Dynamo es una decisión técnica defendible. Las herramientas tampoco tienen que ascender a un lenguaje textual para sentirse realizadas.

Python ayuda cuando la lógica necesita otra forma

Supongamos que empiezan a acumularse reglas: preservar códigos reservados, distinguir ámbitos, explicar por qué una puerta queda bloqueada y resolver prioridades entre condiciones. Si esas decisiones se entienden mejor como funciones que reciben registros y devuelven propuestas, Python puede ayudar a organizarlas. El beneficio está en la estructura que consigues y en cómo compruebas sus resultados; escribir las mismas decisiones de forma opaca no mejora nada por ocupar menos pantalla.

Una frontera útil consiste en entregar al bloque de reglas datos ya leídos: identificador de la puerta, fase elegida, ámbitos candidatos, código existente y configuración aplicable. El resultado puede incluir una propuesta, su motivo y un estado claro. Así puedes razonar sobre una puerta sin recorrer todo el modelo cada vez, y probar muchas combinaciones con ejemplos pequeños. Esa lógica puede comprobarse fuera de Revit si realmente está separada de sus objetos y servicios; no basta con cambiar de extensión al archivo.

Dynamo puede seguir encargándose de seleccionar entradas y presentar resultados mientras un nodo Python concentra esa parte de la lógica. La guía de desarrollo de Dynamo contempla Python, nodos personalizados y bloques de DesignScript entre sus opciones. Combinar representaciones tiene sentido cuando cada una facilita comprender una responsabilidad. No hay ningún premio por introducir tres tecnologías para sumar dos parámetros.

El entorno concreto sigue importando. Un nodo Python dentro de Dynamo depende de su motor y de las versiones y bibliotecas disponibles; no equivale a ejecutar cualquier script del ordenador con acceso libre a Revit. Antes de adoptar un fragmento debes comprobar para qué contexto está escrito y qué dependencias necesita. La guía de migración de motores publicada por Dynamo ilustra por qué ese dato forma parte del mantenimiento.

Si solo una persona entiende Python y varias mantienen Dynamo, trasladar todas las reglas de golpe puede concentrar el riesgo de soporte. Puedes empezar por una operación acotada, documentarla y revisarla con alguien más. La capacidad futura de mantener una herramienta es un criterio de diseño, no un asunto administrativo que aparece después de terminar. De nada sirve ahorrar diez minutos de ejecución si cada ajuste obliga a esperar tres semanas al único intérprete autorizado.

Decide cómo se aplicarán los cambios antes de elegir el envoltorio

La propuesta de numeración debería mostrar puerta, código actual, código previsto y motivo. Si hay dos solicitudes para el mismo número o falta información necesaria, el sistema debe señalarlo de una forma que permita corregir la causa. El usuario tiene que entender qué va a pasar y qué queda pendiente. Esa capacidad de revisión puede construirse con distintos entornos; no viene incluida por usar nodos ni por importar una biblioteca de Python.

Después hay que definir el momento de aplicar. Entre la revisión y la escritura podrían haber cambiado el modelo o la selección. Las comprobaciones críticas deben repetirse, y la operación debe respetar el contexto de la API y la gestión de transacciones de su anfitrión. Una puerta no editable debe producir un resultado identificable. Capturar cualquier excepción y continuar con un mensaje de éxito solo consigue que el fallo llegue más lejos vestido de dato correcto.

También necesitas una política para la segunda ejecución. En nuestro ejemplo, repetir sin cambios debería tener un comportamiento previsto; alterar una regla, en cambio, podría requerir una actualización explícita. Si el flujo renumera automáticamente puertas ya emitidas porque ha variado su orden geométrico, la discusión sobre Dynamo y Python habrá servido de muy poco. La herramienta habrá obedecido una instrucción técnicamente posible que nadie quería aplicar.

Cuando aparecen otros requisitos, la comparación inicial puede quedarse pequeña. Una integración permanente en la interfaz, un despliegue amplio o interacciones con eventos pueden justificar estudiar un complemento y su arquitectura de mantenimiento. Eso no convierte a un grafo en una mala solución para una tarea acotada, ni obliga a empezar por un producto completo. Conviene dimensionar la herramienta para el trabajo y su recorrido probable, evitando tanto la improvisación como el palacio de software para cambiar cinco textos.

Piensa en tres costes a la vez: cuánto cuesta construir, cuánto cuesta revisar el resultado y cuánto costará mantenerlo. Dynamo puede reducir la distancia entre una regla y quienes la discuten; Python puede simplificar una lógica que necesita funciones y pruebas; un complemento puede ofrecer una distribución e interacción más integradas cuando eso está justificado. Ninguna elección evita definir qué significa acertar sobre el modelo.

Una prueba pequeña vale más que una guerra de herramientas

Para tomar la decisión, prepara un conjunto representativo de puertas y ejecuta primero una lectura con propuestas. Incluye casos normales y conflictos que ya conozca el equipo. Comprueba si quien debe usar la herramienta entiende el resultado y sabe qué hacer ante un bloqueo. Una prueba con tres elementos limpios demuestra que tres elementos limpios no se han resistido demasiado. El valor aparece al enfrentar el flujo a las condiciones que suelen romper el trabajo manual.

Si comparas dos alternativas, utiliza las mismas reglas y datos. Observa cuánto tarda otra persona en localizar una decisión, corregir un criterio y comprobar una regresión. Es un contraste más útil que contar nodos frente a líneas de código. Puedes terminar manteniendo Dynamo, introduciendo una función Python o descubriendo que todavía conviene limitarse a detectar duplicados. El ejemplo es una propuesta de evaluación, no el relato de una implantación realizada.

Deja por escrito la elección y sus condiciones: quién mantiene el flujo, con qué versiones se ha comprobado, qué queda fuera y cuándo habría que revisarlo. Si el uso crece o cambia el equipo, esa decisión puede cambiar sin que la anterior fuera un fracaso. El prototipo que permitió aclarar la convención habrá hecho un trabajo valioso incluso si más adelante se sustituye su forma de ejecución.

Elige el entorno que permita expresar la regla, acceder al modelo y entregar una herramienta mantenible por tu equipo. Si la decisión solo se sostiene en que una opción parece más profesional, todavía falta hablar del trabajo. Las puertas no reciben mejor numeración por el prestigio del lenguaje; agradecen una regla inequívoca y alguien que compruebe el resultado.