The Python Toolscape

At the centre of everything sits the Python interpreter - the program that reads your Python and actually carries out the instructions. When people say 'install Python', they mean install this interpreter. Everything else in this lesson is just a different way of feeding code to it.

There are two ways to feed it. The first is interactively, one line at a time, in a prompt called the REPL (read-eval-print loop). You type an instruction, press Enter, and see the result immediately - superb for quick tests:

>>> 3200 / 150      # how many 150mm fins across 3.2m?
21.333333333333332
>>> round(_, 1)
21.3

The second is by writing a script - instructions saved in a .py text file - and asking the interpreter to run the whole thing at once, typically from a terminal:

# save as areas.py, then run:  python areas.py
rooms = {"living": 24.0, "kitchen": 12.5, "bedroom": 16.0}
for name, area in rooms.items():
    print(name, area, "sqm")

That is the whole core idea: the interpreter is the engine, and you either chat with it live (REPL) or hand it a saved script. Every fancier tool below is a nicer wrapper around exactly this.

It helps to demystify one more word here: the terminal (or command line) is just a text window where you type commands to your computer, and python areas.py is one such command - it tells the interpreter to run that file. Designers often find the terminal intimidating because it is bare text with no buttons, but you will only ever need a handful of commands, and the editors below hide most of it behind a Run button anyway. There is nothing mystical under the hood: a file of instructions, and an engine that reads them top to bottom and does what they say.

You could write scripts in plain Notepad, but a proper code editor makes the work far easier - it colours your code so mistakes stand out, auto-indents (which Python cares about), suggests function names, flags errors before you run, and lets you run a file with one keystroke. An editor loaded with these coding features is called an IDE (integrated development environment).

The honest recommendation for a designer starting today is Visual Studio Code (VS Code) - free, cross-platform, hugely popular, and gentle to begin with while scaling up as you grow. Install it, add the official Python extension, and you have a comfortable home for everything in Modules 1 to 4. Python also ships with a tiny built-in editor called IDLE, which is perfectly fine for your very first scripts if you want zero setup.

What do these coding features actually buy you? Concretely: syntax highlighting colours keywords, text and numbers differently so a typo often shows up as the wrong colour before you even run; auto-indentation keeps the four-space blocks Python insists on lined up; autocomplete offers function names as you type so you need not memorise exact spellings; and an integrated run button and error panel let you execute a file and jump straight to the line that broke. None of this changes what your code does - it just removes friction, which matters most when you are new and every error feels mysterious. There are heavier professional IDEs such as PyCharm, but you do not need them, and chasing the 'best' editor is a classic way to procrastinate. Pick VS Code, or IDLE for five minutes, and move on - the editor is a comfortable chair, not the work itself.

A Jupyter notebook is a different way of working that suits designers unusually well. Instead of one long script file, a notebook is a sequence of cells you run one at a time, with each cell's output - a number, a table, a chart, an image - appearing directly beneath it, mixed with your notes.

That make it ideal for exploring: loading a schedule and poking at it, trying a calculation, drawing a quick chart, tweaking and re-running just one cell without starting over. It is how most data and analysis work is done, and it pairs naturally with pandas and matplotlib later in the course. The trade-off, worth being honest about, is that notebooks are built for exploration and presentation, not for building reusable tools you run unattended - for that, a plain .py script is cleaner. A good instinct to adopt: notebook to explore and understand; script to automate and repeat. You will use both, and VS Code happens to open notebooks too, so you need not choose a separate app.

One small gotcha worth flagging now, because it confuses every beginner eventually: in a notebook you can run cells in any order, and the notebook remembers whatever you last ran, not what appears top to bottom. Run cell 3, then edit cell 1 without re-running it, and the notebook is now in a state your file no longer describes - a classic source of 'but it worked a minute ago'. The fix is simple discipline: when something behaves strangely, restart and run all cells top to bottom to get a clean, honest state. Notebooks reward exploration but ask for that little bit of tidiness in return.

Here is the part that makes all this directly useful: Python does not only run in a terminal - it runs inside the design software you already use, driving real geometry and models. Be clear-eyed about how, because the details differ.

In Rhino and Grasshopper, you write Python in a script component on the canvas (historically 'GHPython'; recent Rhino ships a Python 3 script editor and component). Your code receives inputs from other Grasshopper components, does its work, and passes geometry back out - covered in Module 6. For working with Rhino files outside Rhino, there is a separate library, rhino3dm, that reads and writes .3dm geometry from ordinary Python. In Revit, you rarely script Python directly against the software; instead you use Dynamo, a visual programming tool for Revit, which has a Python Script node where you write Python that calls the Revit API to read and edit model elements (Module 7). Tools like pyRevit let more advanced users run Python against the Revit API more directly. One honest wrinkle worth knowing early: for years the Python inside these tools was an older dialect (IronPython, a version of Python 2) that differed in small ways from the Python you run on your desktop. The tools have been moving to modern Python 3, and recent Rhino and Dynamo releases support it, but you may still meet older setups in practice - so if a snippet behaves oddly inside a design tool, the Python version is a fair first suspect. Do not let that scare you off; it is a footnote, not a barrier.

The reassuring truth is that the language is the same everywhere - the loops, variables and logic you learn in Modules 1 and 2 are exactly what you type into a Grasshopper component or a Dynamo node. Only the way code gets its inputs and hands back results changes from tool to tool, and that plumbing is what Modules 6 and 7 teach once the language itself is second nature.

Python comes 'batteries included': a large standard library of ready modules that ship with the interpreter and need no installation - os for files and folders, csv and json for common data formats, math for calculations, random, datetime, pathlib and more. You reach them with import:

import math
print(math.pi)          # 3.141592653589793
print(math.dist([0, 0], [3, 4]))   # 5.0 - straight-line distance

Beyond the standard library sits a vast ecosystem of free third-party libraries you install with one command (pip install ...). Five are worth knowing by name now. pandas handles tabular data - schedules, BOQs, any spreadsheet - and is the backbone of Module 4. numpy does fast numbers and arrays, and underpins most geometry and data maths. matplotlib draws charts. rhino3dm reads and writes Rhino geometry outside Rhino. And requests fetches data from the web. You do not install these yet or memorise them - just recognise the names, because they recur constantly. The map is simple: a standard library that is always there, plus a workshop of installable tools you add as a task demands. That is the whole toolscape - an engine, a few front doors, and a set of toolboxes.