Installation and Setup

It is a Tuesday evening. A friend from your study group sends you a small program as a file named quiz_game.py, along with the message "just run it". You double-click the file and a window flashes open and vanishes. You try again with a right-click and an "open with" menu, and now a text editor shows you something that looks like English but with sentences such as input("Guess a number: "). Nothing is running. The file sits there like a locked door.

You open a search engine and the first result says something mysterious: "type this command into a terminal". A terminal. On a system where your tools so far have been a browser and a word processor, this is the first genuinely new room in the house. That room is where every programmer of every language works, and learning to walk into it on purpose, rather than by accident, is exactly what this lesson teaches.

The good news about timing: the official tooling for getting Python onto a machine was completely rebuilt across 2025 and 2026. On Windows there is now a single supported installer component that keeps itself up to date, and it replaces advice you will find in many older tutorials. If you follow any tutorial that tells you to tick a magic box called "Add Python to PATH", that advice describes the old world. This lesson describes the November 2026 world in the words of the official documentation.

By the end of the lesson you will have the full beginner toolchain working on your own machine: a verified language installation, an editor, a running script and a private workshop for packages. Every command shown here is real, and every one of them is typed by a beginner within the first hour of learning.

1. The Four Tools Behind Every Python Project

Before touching a download button, it pays to know what you are actually putting on your machine, because "installing Python" is really installing a small team of tools that cooperate. The map below is the whole lesson in miniature, so return to it whenever the details get dense.

Reading the map clockwise from the top left:

• Interpreter. The actual Python. When someone says they "installed Python", they usually mean CPython, the official build from the Python Software Foundation, and how to install it is the subject of sections 2 to 5.
• Terminal. The text window. Every verification command, script run and package install in this lesson happens there. You will type far more in it during your first week than in the editor itself.
• Editor. Where source files are written and saved. Any plain text editor can save Python files, but a programming editor highlights your syntax and reports mistakes as you type.
• Package tooling. The pair of pip and venv deserves its own section, and section 7 gives it one. For now, understand a package as code someone else published for reuse, and a virtual environment as a private sandbox that keeps such code from mixing between projects.

One distinction from lesson 1 still matters. Python the language is the set of rules you write in. Python the thing you install is an interpreter that reads those rules and acts on them. This lesson installs a real interpreter and teaches you to talk to it from the terminal.

That vocabulary is enough to check yourself with a matching exercise. Match each tool to the job it actually does, and notice how disjoint the jobs are: editing, running, installing and isolating never overlap.

2. Windows: the Install Manager Era

Windows is both the easiest and the most-changed platform in this lesson, so read this section even if you use another system, because it explains the new tool names used across the ecosystem.

Since Python 3.14, the official way to obtain Python from the CPython team on Windows is the Python Install Manager. In the words of the official documentation, it is a standalone tool that makes Python available as global commands on your machine, integrates with the system, and supports updates over time.¹ You fetch it from two places, and they serve the same component: the page at https://www.python.org/downloads/ and the Microsoft Store app.²

The manager is genuinely new tooling, not a wrapper around the old installer. After it finishes, three commands become available in any new terminal window:

A quiet revolution hides in that list: plain python now simply works. For years, typing python into a fresh Windows terminal either failed or opened a Store page instead of running an installation, which tormented every beginner tutorial ever written. The manager installs real commands, so python runs Python. That trap survives only on machines with very old or partial installs, and the traps section near the end covers it.

Two dated facts set the boundary of the change. The traditional Windows installer has been deprecated since the 3.14 series, and it will not be produced for Python 3.16 or later. The manager itself is young and actively shipped: the latest version as of November 2026 is 26.4, published on 9 October 2026. If a blog post references a checkbox installer or any other tool on a modern Windows machine, prefer the official documentation.

The first verification of this lesson belongs here. Open a new terminal window, which matters because already-open windows do not see newly installed commands, and check:

Concrete expectations keep this honest. On 25 October 2026 the 3.15.2 and 3.14.10 installers were produced, so a fresh machine should print a 3.15 or 3.14 series number. Anything older means an outdated mirror or cached download, and re-downloading from the official page fixes it.

3. macOS: the Signed Official Path

macOS offers several ways to end up with Python, and only one of them is maintained by the Python Software Foundation: the official installer package, a .pkg file downloaded from the python.org downloads page.

Two properties of that file matter. First, the installer packages are signed with an Apple Developer ID Installer certificate, and they are notarized for Gatekeeper, Apple's check for downloaded software. Double-clicking the .pkg therefore behaves politely: no scary warnings and no manual permission bypasses. Second, after installation a folder named Python 3.15 appears in /Applications/Python 3.15/, and the official instructions include one step tutorials often forget:

Double-click the Install Certificates.command file in the /Applications/Python 3.15/ window to complete the installation.

That step fills in the certificates that secure network connections rely on. Skipping it does not break your first print statement, but the first network fetch can fail with a puzzling certificate error whose root cause sits in a folder you were told about on day one.

Verification on macOS accepts two command names. The official python3 --version always names the interpreter available to the shell, and on modern setups python --version also works. Type one, see a 3.15 or 3.14 series number, and the install is done.

The second macOS topic is Homebrew, the popular package system. Honest comparison: brew install python is convenient and well maintained by its own community, but it is not the PSF-supported path. Two differences matter to a beginner. Homebrew's Python can lag the latest release, and it does not bundle the Tcl/Tk dependency that the built-in GUI toolkit tkinter needs; Homebrew provides a separate formula such as python-tk@3.14 for that. Neither difference is fatal, but when a course says "install Python" without qualifiers, it almost always means the official build.

4. Linux: Usually Already There

On most Linux distributions, Python came with the system. The official documentation states it plainly: Python comes preinstalled on most distributions and is available as a package on all others. Your first task on Linux is therefore not installation but identification: find out what you already have.

Notice the command name. On Linux the interpreter is conventionally named python3, because an old python2 lived beside it for so many years that the number became part of the name. Distributions keep their packages stable for long periods, so a preinstalled Python often belongs to an older series than the 3.15 release current in November 2026. That is fine for learning: this course's early lessons run on anything from the 3.10 series upward.

If your distro package is too old for a future lesson, three upgrade paths exist. Distro packages, via commands such as apt on Debian family systems, are the routine choice and can lag the newest series. Tools named pyenv and uv exist because many developers want several versions side by side and pick per project. Building from source is the max-effort path that gets you the newest number.

One habit to carry out of this section: on Linux, reach for python3 unless you have verified that plain python points somewhere sensible.

5. The Verification Habit and the Whole Decision Tree

Everything in sections 2 to 4 collapses into one habit: after any install action on any platform, open a new terminal and ask the machine to state its version. Ten seconds of typing prevents an hour of mysterious failures later, and it is the cheapest debugging skill in existence.

The decision tree below compresses all three platform paths into one picture, and its structure is the real lesson: whichever branch you take, every route ends at the same verification node. The blue nodes are download decisions, the green nodes are post-install actions, and the yellow node is the shared finish line.

Read the tree once for your own platform and once for all of them, because the shared endpoint is the durable lesson. Any Python tutorial assumes you emerge with a version number on screen. A "not recognized" or "not found" message means the gateway node never happened, not that Python is broken.

6. Your First Script and the REPL

With a verified interpreter, the locked door from the opening story opens from two sides. The first side is files: the interpreter reads a .py file you wrote and executes it. The second side is conversation: you type one statement and the interpreter answers immediately, a mode with its own name, the REPL from the glossary.

Start with the file, the conventional first script. Create a file named hello.py in a folder you can find again, type one line, and save it with a .py extension, which tells both your editor and future you what the file is.

Then run it from the terminal, from inside the folder that holds the file:

The interpreter prints Hello, Nuniversity! and returns control to the prompt. The sequence is the loop you will repeat thousands of times: write, save, run, read the output, adjust, repeat.

Now the REPL. Type python or python3 with no file name, and the prompt changes shape, usually to three chevrons, to show that a live session is waiting. In this mode Python files play no role: each statement you type is evaluated and printed on the spot.

Leaving the session properly is worth memorizing. Type exit() and the session ends; on macOS and Linux, the keyboard shortcut Ctrl-D does the same. On Windows, Ctrl-Z followed by Enter does the same. Closing the terminal window while a session runs also works, but a deliberate exit keeps you in the habit of ending things on purpose.

The REPL's superpower is its zero-cost feedback. During lessons 3 and 4 you will test every new operator and data type by typing two characters and pressing Enter, and professional developers keep a session open for exactly the same reason years later: it is the fastest "what happens if" machine ever built.

7. pip and Your First Virtual Environment

Windows, macOS and Linux now each run your code. Two tools remain, and they arrive together because of a practice decision you should make today rather than in six painful months.

First, pip. The standard distribution includes it, and it fetches third-party packages from PyPI, the public catalogue you met in lesson 1. Three commands cover a beginner's needs: check pip --version to confirm pip exists, pip install requests to add a specific useful package, and pip list to see what is installed.

Second, the venv module, and here come the two most important commands in the lesson. A virtual environment is a private folder holding its own package collection, created per project:

That command creates a folder named .venv in the current directory. Creating it does not switch anything; you must activate it, and the activation command differs by system:

On success the terminal emits one subtle, permanent clue: your prompt gains the environment name, typically a (.venv) prefix. From that moment until you type deactivate, every pip install places packages only in that folder, and the interpreter you run picks that folder as its package source.

The full life of an environment is short and repeatable: created, activated, used for installs, deactivated and eventually deleted when the project ends.

Why isolate at all, when pip works globally? Because package versions evolve. Install a package globally today, and a project you build next month may need a different version of that same package; globally installed packages fight each other, and failing builds begin with a sentence every tutorial dreads: "it works on my machine, maybe yours differs". A venv per project ends that class of problem before it starts.

8. uv and Poetry: When pip Starts to Feel Slow

By your third project, pip will have done its job and shown its limits. You will have created .venv again, activated it again, installed six packages, and then tried to explain to a teammate why their identical-looking install behaves differently. Nothing is broken. pip simply has no memory of the exact versions you resolved last Tuesday.

Two modern tools fix that, and both are worth knowing by name in 2026. uv is a single fast binary written in Rust that installs Python itself, manages environments, resolves dependencies, runs scripts and runs tools.³ Poetry is the older, packaging-focused option that many libraries and teams still use.⁴

They share one idea. Instead of a loose requirements.txt, a project declares its dependencies in pyproject.toml, and the tool writes a lock file with the exact versions it resolved. pyproject.toml records what you asked for, usually as version ranges. uv.lock or poetry.lock records what you actually got, so every machine installs the same tree.

uv: one binary for the whole toolchain

Install uv with the standalone script, then let it install the interpreter too. On macOS and Linux the command is one line. On Windows use the PowerShell form.

A new project then takes four commands. Read them as a sentence: install Python, create the project, add a dependency, run the program.

Four details make the workflow click:

• uv init writes pyproject.toml, pins an interpreter in .python-version, and creates a src folder for your code.
• uv add requests edits pyproject.toml and refreshes uv.lock in one step, so the declaration and the lock never drift apart.
• uv run quiz-game syncs the environment if needed and runs the project's declared command. You never activate anything by hand.
• uv sync rebuilds the environment from uv.lock on a teammate's machine or in continuous integration.

Two extras are worth filing away. uvx ruff check . downloads and runs a tool in a temporary environment, so a linter never pollutes your project. And uv self update upgrades uv when it was installed with the standalone script.

Poetry: the established packaging workflow

Poetry predates uv and still has a large user base. Version 2.5.1 shipped on 20 September 2026, and Poetry requires Python 3.10 or newer. Unlike uv, it does not install an interpreter for you, so bring the Python you installed in sections 2 to 4.

Install Poetry in its own isolated environment with pipx, then create a project. Poetry keeps its environments outside the project folder by default, which is why you run commands through poetry run rather than activating a local .venv.

Three behaviours differ from uv in ways that matter:

• poetry new produces pyproject.toml, a README.md, a src package and a tests folder, a layout aimed at publishable libraries.
• poetry add updates pyproject.toml and poetry.lock together, and poetry install follows the lock exactly when one exists.
• poetry env activate prints the shell command that activates the project environment, while poetry config virtualenvs.in-project true puts a .venv inside the project if you prefer the layout used by pip.

Since Poetry 2.0, dependencies can live in the standard [project] table defined by PEP 621, so a Poetry project is still an ordinary pyproject.toml project. You are not locked into a private format, and moving away later is realistic.

Follow the lock file first, because a team's existing choice beats personal preference. When the choice is yours and the project is new, the tree points at the workflow that matches your experience.

Comparative Verdict: which tool should a beginner learn first

• pip and venv first, always. They are already installed, every tutorial assumes them, and they teach the concepts of environment and package that the modern tools automate. Skipping them makes debugging harder later.
• Add uv as your second tool. One binary covers interpreter installs, dependencies, locking, running code and one-off tools. The uv.lock file and uv run remove two entire classes of beginner mistakes.
• Choose Poetry when a team or library already uses it. Its packaging workflow is mature, its lock file is well understood, and its commands map closely to the concepts you already learned. It is a fine destination, not a required detour.
• Verdict: learn pip and venv this week, install uv next week, and treat Poetry as the tool you adopt when a project asks for it.

9. Choosing an Editor That Fits How You Think

An editor is where you will spend actual hours, so the choice is about comfort, not correctness: any of these three can write every line in this course.

• VS Code with the Python extension. The common free path: lightweight, syntax highlighting, inline mistakes and a run button. The community default for a first editor.
• PyCharm Community. A full IDE with refactoring, a debugger and project management. More to learn, and the free edition suffices for this course.
• IDLE. Ships with CPython, so it is already installed and doubles as a REPL. Fine for the first week, outgrown quickly.

A practical first-week algorithm: open IDLE tonight and feel the REPL; move to VS Code when a project spans more than one file; consider PyCharm when you want structure, tests and refactoring. Switching later is normal.

Save files with plain .py extensions and keep the encoding at UTF-8. Since Python 3.15, text handling defaults to UTF-8 (PEP 686), and the official advice still suggests naming an encoding explicitly when a program writes text files. An editor that saves exotic encodings creates problems no Python knowledge resolves quickly, so set UTF-8 once and leave it.

Traps That Burn a Beginner's First Week

Every section above had a happy path. These four traps recur in the official documentation and in every beginner forum, and each has a thirty-second antidote.

1. The Store-stub ghost on old Windows advice. On old-style machines, typing python opened the Microsoft Store instead of an interpreter. With the Install Manager the command works, so Store-opening behaviour means the machine is running old advice against new tooling; re-run the flow in section 2.
2. The Homebrew lookalike. A tutorial written for the PSF build can fail on a Homebrew build in GUI corners, because Tkinter and the install layout differ. Check where your Python came from before debugging the code.
3. The global pip sprawl. It rarely hurts on day one: the projects whose installs break first are always the second and third ones.
4. The encoding surprise. An editor set to a non-UTF-8 encoding combines badly with a language that now defaults to UTF-8. One preference tick fixes it.

2026 Updates (as of November 2026)

Practice Questions

Answer these before moving to the next lesson. Questions q1 to q6 appear inside their topic sections above, and the six below are the cumulative set, so every question is answerable from this lesson alone. Each explanation names both why the correct answer is correct and why the strongest wrong option traps, so reading them after self-checking is revision too.

Dig deeper

What Comes Next

The toolchain is assembled: a verified interpreter answers version commands, an editor is chosen, a hello.py runs, a REPL session answers statements, and one .venv holds a package per project. Lesson 3 finally becomes the writing lesson you expected at the start: variables and types, with your own machine as the laboratory rather than a reading exercise.

If you want one long, friendly video companion to pair with this course, the freeCodeCamp recording below covers installation and first programs exactly as this lesson does, at full university length, and it is free.

References

Every factual claim links to its source, with the access date printed so the source can be rechecked.

1. [1]Python on Windows: the Python install managerDocumentation

   Python Software Foundation · Accessed 2026-11-06

2. [2]Downloading PythonDocumentation

   Python Software Foundation · Accessed 2026-11-06

3. [3]uv documentationDocumentation

   Astral · Accessed 2026-11-06

4. [4]Poetry documentationDocumentation

   Python Poetry · Accessed 2026-11-06