A Python Development Workflow

Start from the task, not from the tool

A Python workflow begins with a task, not with an editor. Automate repeated file changes, build a small application, create tests, or provide programmable behavior inside another system: the problem decides what code and which libraries are needed, and no tool makes that decision for you.

Three questions settle the shape of the program before a line is written.

Python supports both quick automation and structured programs that can grow beyond a shell script, which is why the same language can carry a throw-away answer and the maintained tool it becomes.

Explore at the prompt

The first contact with a new idea should be cheap. The interactive interpreter reads and executes commands when its standard input is connected to a terminal. Type an expression, see the value; call a function, see what it returns.

This mode earns its place in three situations:

• Trying an expression whose behavior you are not sure about.
• Exploring a language feature you have just read about.
• Testing a function while you are still writing it, before any program uses it.

The result is immediate, so the feedback loop is as short as it can be: the gap between a wrong assumption and the evidence that it is wrong is one line.

Interactive mode also tells you where you are. Commands read from a terminal are prompted with the primary prompt, usually three greater-than signs, and continuation lines inside a multi-line construct are prompted with three dots. Seeing the secondary prompt is how you notice that the interpreter is still waiting for the rest of an if statement rather than ignoring you.

What this mode is not is a place to keep work. Everything typed at the prompt exists for as long as the session does. That is a feature while exploring — nothing accumulates, nothing has to be cleaned up — and a problem the moment the same result is needed twice.

Save what works as a script

Exploration is not the final form of a repeatable program. When the interpreter is invoked with a file name or a file as standard input, it reads and executes a script from that file. Saving the code that worked turns a session into an artifact: it can be run again, edited, reviewed and corrected.

The move from one to the other is the first real step of the workflow, and it usually happens the second time you find yourself retyping the same three lines.

Setup from a file, then keep exploring

The two modes are not rivals, and there is a documented way to use both in one run. Passing -i before a script runs the script and then enters interactive mode, combining repeatable setup with continued exploration.

That hybrid fits a very common moment: the objects you want to inspect take several lines to build, and building them by hand every time is exactly the retyping a script removes. The file does the setup; the prompt does the inspecting.

Read the difference as a matter of what happens after the last line of the file:

The order matters: -i goes before the script name, because it is an option for the interpreter rather than an argument for the program.

Running a module, and naming the interpreter

Some modules are useful as programs in their own right. A module can also be executed as a script with the python -m module form, which executes the source file for that module as if its full name had been spelled out on the command line.

That is worth knowing early for a practical reason: it means a reusable module does not have to choose between being imported by other code and being run directly.

One caveat applies to every command above. Launcher names and interpreter locations vary by platform and installation, so the locally appropriate Python command must be used. On many Unix systems the interpreter is installed under a versioned name; on Windows it may be available through a store installation or through the py launcher.

Writing python in a lesson is shorthand for "the command that starts Python here". Finding out what that command is on your own machine is a one-minute job worth doing before the first script.

Split responsibilities instead of copying code

As a program grows, the pressure is to copy the part that works into the next program. That is the moment to divide responsibilities instead. Python allows a program to be split into modules that can be reused by other Python programs.

The test is simple: if the same behavior is needed in two places, it belongs in one place that both can use. Copied code has to be corrected in every copy, and the copies drift apart quietly.

A worked example makes the boundary visible. A file-processing utility grows to hold three responsibilities: parsing a record, deciding what to do with it, and writing the result. A second program needs only the parsing.

Nothing is lost by the split. The parsing code is still ordinary Python, run by the same interpreter, and it can still be tested at the prompt while it is being written.

Choose existing facilities before writing your own

Before writing a capability, check whether it is already distributed. Python includes standard modules that can serve as the basis of programs, including facilities for file input and output, system calls, sockets, and graphical interfaces. They can be used as the foundation of your program, or read as examples while learning.

The wider ecosystem offers third-party components in addition to the standard library. Evaluate one when the required capability is not provided by the language or by the distributed library — that order keeps a project's dependencies down to the ones it actually needs.

The whole path is therefore a loop rather than a straight line: define the task, experiment interactively, save working code as a script, organize reusable responsibilities as modules, and select library support. A later edit re-enters the same loop — reproduce the behavior, test a smaller idea at the prompt, update the saved code, keep the reusable parts separate.

• Use interactive mode for immediate experiments and a script for repeatable execution.
• Move reusable responsibilities into modules instead of duplicating code.
• Start with built-in and standard-library facilities, then consider third-party packages for additional capability.

Later lessons teach the syntax and the operational detail behind each stage; this is the map they fit into.