Python in Dynamo

Dynamo is an add-in that most designers open inside Revit, though it also runs standalone as Dynamo Sandbox and inside Civil 3D. Its canvas is a directed graph: data enters nodes on the left, flows through them, and leaves on the right. A typical Revit graph might be Categories -> All Elements of Category -> Element.GetParameterValueByName - three boxes, no code, and it reads every wall in the model and pulls a parameter. For a great deal of BIM work you never write a line of Python; you compose nodes.

The Python Script node is the escape hatch for when nodes are not enough. You add it by searching the library for Python Script, or right-clicking the canvas. Double-click it and an editor opens with a starter template already filled in. In a Revit session the template wires up the API references for you; the important lines are the two that connect code to canvas:

# Inputs are provided in the IN list; the result goes to OUT
dataEnteringNode = IN
OUT = 0

Everything you type between reading IN and assigning OUT is ordinary Python. You can loop, branch, build lists and dictionaries, import from the standard library, and call the Revit API. The node itself is just a container: Dynamo hands your code the inputs, runs it top to bottom, and takes whatever you put in OUT back onto the wire. Think of it as writing one custom node whose behaviour is exactly the code you want - the missing box you draw yourself when the library does not have it.

The whole contract of the node is two names. `IN` is a list of the node's inputs, and `OUT` is the single value the node returns. When you add a Python Script node it starts with one input port; drag the little + at its bottom-left to add more. The first wired port is IN[0], the second IN[1], and so on - a plain Python list, in port order.

So if you wire a list of room areas into the first port and a threshold number into the second, your code reads them like this:

areas = IN[0]         # a list of numbers from the wire
threshold = IN[1]     # a single number

large = []
for a in areas:
    if a > threshold:
        large.append(a)

OUT = large

Dynamo converts between its own data and Python transparently: a Dynamo list arrives as a Python list, a number as a float or int, text as a str. Whatever you assign to OUT travels back out - a list becomes a Dynamo list, a dictionary becomes a dictionary, a single value a single value. One catch matters constantly in Revit work: elements coming from the graph arrive wrapped in Dynamo's own type, not as raw Revit API objects. Before you can call API methods on them you unwrap them with UnwrapElement(IN[0]), and if you build new Dynamo geometry to send back out you may need to wrap it. Get IN, OUT and UnwrapElement straight and the boundary stops being mysterious - it is just a list in and one value out.

A Python Script node does not run Python by magic - an engine interprets it, and Dynamo ships with two. For years the only option was IronPython 2.7, an implementation of Python 2 that runs on Microsoft's .NET framework. Because Revit itself is a .NET application, IronPython could talk to the Revit API very directly, which is why almost every older Dynamo script and forum answer is written for it. But Python 2 reached end of life in 2020, and its print statement, integer division and text handling all differ from modern Python.

Today Dynamo defaults to CPython3 - the standard, current Python 3 you learn everywhere else in this course, bridged to .NET through a library called Python.NET. This is the engine you should choose for new work: print() is a function, division of two integers gives a float, f-strings work, and the language matches the rest of the world. You pick the engine from a small dropdown at the bottom of the node, or pin it with a comment on the first line:

# engine: CPython3
print("hello from Python 3")
OUT = 1 / 2   # -> 0.5, not 0

The difference is not only syntax. The two engines expose the Revit API slightly differently - handling of output parameters, .NET enums and some collections varies - so a script copied from an old blog may fail under CPython3 and need small fixes, or vice versa. The practical rule: write new scripts in CPython3, and when you paste in old IronPython code, expect to adjust prints, division and the odd API call rather than assume it just runs.

The Python node is powerful, but reaching for it too early makes graphs worse, not better. A well-built Dynamo graph is self-documenting: a reviewer sees the flow of boxes and understands it. A Python node is opaque by comparison - its logic hides until someone opens the editor. So the honest guidance is to stay visual for as long as the nodes read clearly, and drop into Python only where the graph would otherwise become a knot of wires.

Good reasons to write code: a loop with a branch inside it (much cleaner as five lines of Python than as List.Map plus If plus List.FilterByBoolMask); string work like building sheet names from parts; a bit of maths or an algorithm with no matching node; or calling a Revit API method that Dynamo simply has not wrapped as a node. Good reasons to stay with nodes: reading and setting parameters on a category, filtering lists, and simple geometry - all of which have clear, readable nodes already.

A common and very healthy pattern is to mix the two: let the graph gather inputs and select elements with legible nodes, feed those into a compact Python node that does the awkward logic, and let the graph take the result onward to write it back. Your Python stays small and focused - the interesting decision, nothing more - and the surrounding graph keeps the whole thing readable. Scripting inside Dynamo is not a rejection of visual programming; it is visual programming with a sharper tool available for the parts that need one. Keep the code node lean, comment what it does, and you get the best of both worlds.

Code that runs cleanly in a plain file can still misbehave inside a node, so knowing how to see what your script is doing is part of using the Python node well. Your first tool is print. Anything you print from inside the node is captured by Dynamo, so scattering a few prints to check the value of a variable, the length of a list, or which branch a condition took is the quickest way to understand a script that is not behaving.

values = IN[0]
print("got", len(values), "values")   # shows up in the node output
total = sum(values)
print("total is", total)
OUT = total

When a script genuinely fails, the node turns yellow or the graph reports an error, and the message usually names the line and the problem - a TypeError, an AttributeError from calling a method on the wrong kind of object, or the classic NoneType error when LookupParameter returned nothing and you used it anyway. Read the last line of the message first; it is almost always the real cause. Because Dynamo runs the node top to bottom, an error stops at that line, so a print just above the failing line tells you the state of things right before it broke.

A second habit that saves grief is to build up a script in stages rather than all at once. Wire the inputs, print them, and run - confirm the data arriving is what you think. Then add the loop, printing inside it, and run again. Only once the middle behaves do you assign the final result to OUT. This is the same incremental style the debugging lesson in Module 10 preaches, and it matters even more here because a node hides its internals: the smaller the step between runs, the less you have to search when something breaks.

One last practical point: the node re-runs whenever its inputs change or you edit the code and click Run, so you get a fast feedback loop. Change a value upstream, watch the output update; tweak the code, run, read the print. That tight loop - edit, run, read, adjust - is how you actually develop a script inside Dynamo, and it turns the Python node from an intimidating black box into an ordinary, inspectable piece of your graph.