We finished the previous lesson with the choice made: Python. Now comes the most down-to-earth part of the module, and probably the one that causes beginners the most frustration. Before writing code you have to set up the workstation: install the interpreter, get hold of a decent editor, learn to use the terminal and organise your files so that in three weeks' time you can still find them.

This part is usually dispatched with a "just install Python and off you go", after which people get stuck for hours on a python: command not found that nobody has explained to them. We are not going to do that here: we will look at which pieces make up a development environment, how to install them on all three operating systems, how to check they work and what to do when they do not.

By the end of the lesson you will have a working environment and you will have created and run easytask.py, the file we will keep extending until the end of the course.

1. What a development environment is and which pieces make it up
2. The terminal: the tool nobody introduces you to
3. Installing Python 3 on Windows, macOS and Linux
4. Checking the installation
5. The interactive interpreter (REPL)
6. Running a .py file
7. Text editor versus IDE
8. Minimal VS Code setup for Python
9. Folder structure of a small project
10. Virtual environments with venv
11. Creating and running easytask.py
12. Common mistakes and tips
13. Exercises
14. Conclusion

A development environment is the set of tools with which you write, run and fix programs. It is not a product you install in one go: it is several pieces working together.

The first four are essential from today. Virtual environments we will cover here because it is worth picking up the habit early. Git we mention and leave for Version control: it is important, but adding it now would overload the first week.

The terminal (also "console" or "command line") is a window where you type orders as text and the system carries them out. It feels awkward at first because there is nothing to click, but it is where Python is launched, so there is no avoiding it.

You only need four orders for the whole course:

The key concept is the working directory: the terminal is always "positioned" in a folder, and orders are carried out relative to that folder. If you type python easytask.py while in the wrong place, the system will tell you it cannot find the file. That is not a Python error: it is that you are in a different folder. This misunderstanding causes, by a wide margin, most of the first day's blockages.

Two shortcuts that save a lot of time:

• Tab autocompletes file and folder names. Type east and press Tab.
• Up arrow brings back the previous order. You will use it hundreds of times to re-run the program after each change.

We need Python 3.10 or higher. Any recent 3.x version will do for this course.

On Windows, the warning bears repeating because it is failure number one: if you do not tick "Add Python to PATH", the terminal will not find the python command and you will get a baffling error. If you have already installed without ticking it, launch the installer again, choose Modify and enable it.

On macOS, one detail: Macs ship with a system Python that may be out of date and is best left alone, because the operating system itself uses it. Install one of your own with Homebrew or with the official installer.

Open a new terminal (important: ones already open do not see PATH changes) and type:

You should see something like:

If instead you get Python 2.7.x, or a command-not-found error, try:

On macOS and Linux the correct command is usually python3, because plain python was historically reserved for version 2. Use whichever works for you and be consistent throughout the course.

Check the package manager too:

If pip is not available, try pip3 --version or, on any system, the most robust form:

This last form — python -m pip — is the most reliable because it explicitly uses the pip associated with the Python you are running, and avoids confusion when several versions are installed.

Python offers two ways of running code, and it is worth understanding the difference properly.

The first is the interactive interpreter or REPL (Read-Eval-Print Loop: read, evaluate, print, repeat). You open it by typing python and nothing else:

Something like this appears:

The three >>> symbols are the prompt: Python is waiting for you to type something. Each line you type runs when you press Enter and its result is shown immediately:

Notice one detail: typing 2 + 3 shows 5 with no need for print. The REPL automatically shows the value of what you type. This only happens here; in a .py file, if you want to see something you have to ask for it with print.

To leave the REPL:

Ctrl+D (macOS/Linux) or Ctrl+Z followed by Enter (Windows) also work.

What the REPL is really for: trying isolated things out. What does this operation return? How exactly is this instruction written? Is this thing I think is 5 actually 5? It is an instant test bench, and you will use it constantly during the course.

What it is not for: writing programs. Everything you type in the REPL disappears when you leave.

The second way — the one we will use for EasyTask — is to write the code in a text file with the .py extension and ask Python to run the whole thing.

Suppose we have a file called easytask.py with this content:

From the terminal, positioned in the folder where the file is, you run it like this:

And the output is:

The full process, step by step:

That loop — edit, save, run, look — is literally what programming consists of. You will repeat it thousands of times. Two warnings that save grief:

• Save before running. Python reads the file from disk, not what you see on screen. If you have not saved, it runs the previous version and you go mad wondering why the change has no effect.
• Be in the right folder. If you get can't open file 'easytask.py': No such file or directory, check with ls (or dir) that the file is where you are.

You could write Python in Notepad, but it would be like drawing a spreadsheet by hand. The tools fall into two families.

A code editor is a text editor with superpowers for programming: it colours the syntax, autocompletes, flags errors. An IDE (Integrated Development Environment) adds an integrated set of tools: debugger, project management, test running, refactoring.

The recommendation for this course is VS Code: it is free, works the same on all three systems, has excellent Python support and is what you will most likely find in a professional setting. If you feel completely lost with the installation, Thonny is a perfectly respectable alternative for the first few weeks: it brings its own Python built in, so it sidesteps every problem in section 3.

These are the features that will really serve you, whichever tool you use:

• Syntax colouring. Text, numbers and keywords in different colours. When a whole stretch of text is coloured wrongly, it is almost always an unclosed quote: the editor is warning you of an error before you run anything.
• Error underlining. A wavy red underline beneath a missing parenthesis.
• Autocompletion. Type pri and it offers print. It prevents typos.
• Automatic indentation. Critical in Python, where indentation is part of the syntax.
• Integrated running. A play button that launches the file without going to the terminal.

Four steps and no more. The temptation to install twenty extensions on day one ends in a slow editor full of warnings you do not understand.

Step 1. Install VS Code. From code.visualstudio.com, the standard installer for your system.

Step 2. Install the Python extension. Open the extensions panel (Ctrl+Shift+X or Cmd+Shift+X), search for Python and install the one published by Microsoft. It brings Pylance with it, which gives autocompletion and error detection.

Step 3. Select the interpreter. Press Ctrl+Shift+P (Cmd+Shift+P on Mac), type Python: Select Interpreter and choose your Python 3. If you later create a virtual environment, this is where you will select it. This is the step people skip and then do not understand why the editor recognises nothing.

Step 4. Open the project folder, not the lone file. Use File → Open Folder and open the whole EasyTask folder. VS Code works with the notion of a project: if you open an isolated file, you lose half the features and the integrated terminal starts in the wrong place.

Two optional settings that are much appreciated: turning on Auto Save (File → Auto Save), which removes the run-without-saving problem at the root, and opening the integrated terminal with Ctrl+` (or via Terminal → New Terminal), which starts already positioned in the project folder.

A one-lesson program fits in a single file. EasyTask, by the end of the course, does not. Starting with a tidy minimal structure takes five minutes and saves a great deal later.

The rules worth respecting from day one:

• One folder per project. Do not mix EasyTask with the course's loose exercises. Have, for example, programming-course/easytask/ and programming-course/exercises/.
• Names with no spaces and no non-ASCII characters. easytask.py, not Easy Task.py and not easytásk.py. Spaces complicate terminal orders, and accented or non-English characters cause problems across systems.
• Lower-case names with underscores when there are several words: task_manager.py. It is the Python convention and we will follow it all course.
• Never name a file after a Python library. If you create random.py or json.py, your file will mask the system's one and you will get incomprehensible errors. This mistake shows up every year on thousands of forums.

The README.md file is plain text where you explain what the program does and how it is launched. It seems unnecessary when you are the only person using it; it stops seeming so the moment you come back to the project three months later. We will treat it properly in Documentation and comments.

This section solves a problem you do not have yet, which is why it deserves an explanation before any commands.

The problem. Third-party libraries are installed with pip. If you install them "in the system Python", all your versions are shared by all your projects. Imagine EasyTask needs version 1.0 of a library and a later project needs 2.0, which changed things: installing 2.0 breaks EasyTask. With two projects it is annoying; with ten it is unmanageable. On top of that, when you hand the project to someone else there is no way of knowing what exactly it needs.

The solution. A virtual environment is an isolated copy of Python, with its own libraries, living inside the project folder. Each project has its own, and what you install in one does not affect the others.

Creating the environment. Positioned in the project folder:

This creates a .venv folder with the isolated copy. The leading dot marks it as hidden and is the usual convention.

Activating it. Here there are differences by system:

When it is active, the terminal prompt shows the name in parentheses:

That (.venv) is confirmation that everything you install with pip will go to the project's environment and not to the system. To deactivate it:

A note for Windows: if PowerShell responds with an execution policy error, run Set-ExecutionPolicy -Scope CurrentUser RemoteSigned once and confirm. It is a Windows security mechanism, not a Python fault.

An honest warning: during the first modules of this course you will not install any external library, because Python ships with everything needed. So if this feels like too much right now, you can carry on without a virtual environment and come back to this section later. It is included here because this is where it belongs and because it is worth picking up the habit before you have the problem.

Time to put it all together. We are going to create the file that will stay with us until module 9.

Step 1. Create a folder called easytask somewhere you will remember (Documents, for example).

Step 2. Open VS Code, File → Open Folder, and select that folder.

Step 3. Create a new file called exactly easytask.py (with the .py extension; without it, the editor will not know it is Python and will colour nothing).

Step 4. Type this content:

The first three lines begin with #: they are comments. Python ignores them completely when running; they are there for the people who read the file. It is the first good practice of the course and we will keep it up: every file starts by saying what it is and what it is for.

Step 5. Save with Ctrl+S (Cmd+S on Mac).

Step 6. Open the integrated terminal (Ctrl+`) and run:

You should see exactly this:

If you have got this far, you have a working development environment and the project under way. The program still does nothing useful — it only shows text — but it is already real: it is on your disk, you ran it yourself and we will keep extending it module by module.

python: command not found on Windows. "Add Python to PATH" was not ticked during installation. Reinstall by choosing Modify and enable the box. Remember to open a new terminal afterwards.

The command is python3, not python. Very common on macOS and Linux. Check which one works with python3 --version and use that one throughout the course. Mixing them causes confusion that is hard to diagnose.

can't open file 'easytask.py'. You are not in the right folder. Run ls (or dir) to see the files where you are, and cd to move around. Opening the folder in VS Code and using the integrated terminal avoids this problem almost every time.

Running without saving. You change the code, run it and see no difference. Python reads the file from disk. Turn on Auto Save and forget about it.

Saving the file without the .py extension. If the editor saves it as easytask.py.txt (Windows hides known extensions by default), Python will not recognise it. Turn extensions on in the file explorer.

Naming a file after a standard library. random.py, json.py, math.py, test.py. Your file masks the system's one and causes absurd errors that are impossible to connect to their cause. Use names specific to your project.

Copying code from a website with odd characters. Some pages replace straight quotes " with typographic quotes " ". Python does not accept them and gives a baffling syntax error. If you have copied something and it fails for no reason, retype the quotes by hand.

Trying to install five tools on day one. Python, an editor and the terminal. Nothing else. Every extra piece is a source of problems you cannot diagnose yet.

A tip: note down in the README.md the exact command that works for you (python or python3, the folder path). In two weeks' time you will be grateful.

Carry out these checks and note down the exact result of each one:

1. Open a terminal and find out your Python version. State whether the command that works is python or python3.
2. Find out the pip version using the robust form with -m.
3. Enter the REPL, work out how many characters the text "Alba Studio" has and exit properly.
4. Show the directory your terminal is currently positioned in.

For each situation, decide whether you would use the REPL or a .py file, and justify the choice:

1. You want to check quickly whether "high" > "low" returns true or false.
2. You are building EasyTask's menu screen, which is twelve lines long.
3. You want to show Marta how the program works in two weeks' time.
4. You cannot remember whether len works with text and you want to settle it in five seconds.

Set the project up from scratch by following these steps:

1. Create a folder called easytask.
2. Inside it, create easytask.py with an example task card (title, description, assignee, priority and status) using only print. Use fictional data consistent with Alba Studio.
3. Create a README.md with the project name, a one-sentence description and the exact command to run it.
4. Create a virtual environment called .venv and activate it.
5. Run the program and check the output.

Solution 1.

1. python --version or python3 --version, depending on the system. Output along the lines of Python 3.12.3. On Windows python usually works; on macOS and Linux, almost always python3.
2. python -m pip --version, with output similar to pip 24.0 from /usr/lib/python3/dist-packages/pip (python 3.12). The -m form is preferable because it guarantees that the pip used matches the Python you are running.
3. Full session:

That is 11 characters: 4 for "Alba", 6 for "Studio" and the space. The space counts as a character, which surprises a lot of people.

4. pwd on any of the three systems (it works in PowerShell too).

Solution 2.

1. REPL. It is a one-second spot check that does not need to be kept. (Incidentally: it returns False, because in alphabetical comparison the h of "high" comes before the l of "low".)
2. File. It is program code: it has to persist, be modifiable and be run many times over.
3. File. Only a file can be saved, run whenever needed and passed to someone else. Whatever is typed in the REPL disappears on exit.
4. REPL. Immediate doubt, immediate answer: len("hello") returns 5. Yes, it works with text.

Solution 3.

Contents of easytask.py:

Contents of README.md:

Terminal commands, positioned in the easytask folder:

If running it shows the card on screen and the prompt displays (.venv), the project is correctly set up.

A note on the result: notice how clumsy it is to write a card with print line by line. If tomorrow you want a second task, you have to duplicate the ten print statements and edit them by hand. That awkwardness is exactly the problem that variables solve, and it is the first thing we will see in module 2.

You now have a workstation. A development environment is several pieces working together: the Python 3 interpreter, an editor (VS Code, with Microsoft's extension and the interpreter selected), the terminal — where the essential thing is knowing which folder you are in — and the pip package manager. You have learned to install and verify Python on all three systems, to tell the REPL (quick, volatile tests) from running a .py file (real programs, which persist), to organise the folders of a small project and to isolate its dependencies with venv.

And, above all, easytask.py now exists: a real file, on your disk, that you run yourself and that will grow over eight modules until it becomes a complete task manager. Right now it only prints fixed text, and in the last exercise's solution you have seen the first serious limitation of that approach: changing any piece of data forces you to edit the code by hand.

Before we start solving that with code, one last piece of the module is missing, and it is the one that separates whoever programs from whoever copies code: thinking before writing. In the next lesson, From problem to algorithm, we will see what an algorithm is and what properties it must satisfy, how to break a problem down into steps, how to express it in pseudocode and in flowcharts, and how to check it by hand with a desk check. We will apply it to two specific EasyTask operations: registering a new task and deciding which task Marta tackles first.