PythonSetting Up Your Environment

Setting Up Your Environment

Before you write a single line of Python, it's worth spending a little time choosing the tools you'll write it in. A good editor setup catches mistakes before you run your code, formats your files consistently, and lets you run and debug scripts without leaving the keyboard. A bad setup means fighting with your tools instead of learning the language. This page walks through the most popular editor and IDE choices for Python, how to configure the most common one (VS Code) properly, and how to lay out a project so it stays manageable as it grows.

Choosing an Editor or IDE

There's no single "correct" tool for writing Python — the right choice depends on what you're building and how much structure you want out of the box. Three options cover almost every use case you'll run into as a beginner or professional developer.

  • VS Code — a free, lightweight, general-purpose code editor from Microsoft. With the official Python extension installed, it becomes a fully capable Python environment: linting, formatting, debugging, Jupyter notebook support, and an integrated terminal, all in one place. It's the most widely used editor for Python today and the one this page focuses on configuring.

  • PyCharm — a dedicated Python IDE from JetBrains. The Community edition is free and open-source, and is excellent for pure Python projects (strong refactoring tools, a built-in debugger, and deep code intelligence out of the box, no extensions required). The Professional edition is paid and adds web framework support (Django, Flask), database tools, and remote development features.

  • Jupyter / JupyterLab — not a general editor, but a notebook interface where you write and run code in cells and see output (including plots and tables) inline. This is the standard tool for exploratory data science, data cleaning, and quick experimentation, though it's a poor fit for building larger applications or libraries.

Editor

Best for

Cost

Learning curve

VS Code

General-purpose development, scripts, web apps

Free

Low

PyCharm Community

Pure Python projects, learning good habits

Free

Low–Medium

PyCharm Professional

Django/Flask apps, database-backed projects

Paid

Medium

Jupyter / JupyterLab

Data exploration, prototyping, teaching

Free

Low

If you're just starting out and aren't sure which to pick, VS Code is the safest default: it's free, works well for every kind of Python project, and the skills you learn configuring it (interpreter selection, linting, formatting) carry over to almost every other editor. Reach for PyCharm Professional later if you find yourself building a Django or Flask app and want batteries-included tooling, and reach for Jupyter when you're exploring a dataset rather than building something you'll ship.

A Quick Word on Virtual Environments

Once your editor is installed, resist the urge to install every package you need directly into your system's Python. As soon as you start a second project, you'll likely need a different version of some library — and installing everything globally makes conflicts like that inevitable. The standard fix is a virtual environment: an isolated, per-project copy of Python and its packages. It's good practice to create one the moment you start a new project, even a small one. The commands and details for creating and managing virtual environments (venv and beyond) are covered in the dedicated Virtual Environments page — for now, just know that it's a step worth building into your habits from day one.

Warning
Avoid running pip install for project-specific packages directly against your system Python. It works at first, but it quietly turns your global interpreter into a dumping ground where every project you've ever worked on shares (and eventually fights over) the same package versions.
Configuring the VS Code Python Extension

Installing VS Code and the Python extension (search for "Python" by Microsoft in the Extensions view) gets you most of the way there, but a few settings make the experience much smoother.

Selecting the interpreter

VS Code needs to know which Python installation — or which virtual environment — to run your code with. Open the command palette with Ctrl+Shift+P (Cmd+Shift+P on macOS), type "Python: Select Interpreter", and choose the interpreter you want to use for the current workspace. The selected interpreter's path appears in the status bar at the bottom of the window, so you can always check at a glance which Python VS Code is pointed at.

  • Open the command palette: Ctrl+Shift+P

  • Type: Python: Select Interpreter

  • Pick the system Python, or the interpreter inside a project's virtual environment folder

Enabling linting

A linter analyzes your code without running it and flags likely bugs, unused imports, and style violations as you type. VS Code supports both Pylint (thorough, opinionated) and Flake8 (lighter weight) through their own extensions. Install one, then enable it from the command palette with "Python: Select Linter". Once enabled, problems show up as squiggly underlines in the editor and in the Problems panel.

Enabling formatting

Formatting is different from linting: instead of flagging problems, a formatter rewrites your code into a consistent style automatically. Black is the de facto standard Python formatter — it's deliberately opinionated and has almost no configuration options, which means you stop arguing about style and just let it decide. Install the Black Formatter extension, then set it as your default formatter and turn on format-on-save.

JSON
{
  "python.defaultInterpreterPath": "${workspaceFolder}/.venv/bin/python",
  "python.linting.enabled": true,
  "python.linting.pylintEnabled": true,
  "[python]": {
    "editor.defaultFormatter": "ms-python.black-formatter",
    "editor.formatOnSave": true
  }
}
Note
These settings go in your workspace's .vscode/settings.json file (VS Code creates this automatically the first time you change a setting for just the current project). Keeping them in the project rather than your global user settings means the whole team gets the same interpreter path and formatting behavior when they open the repo.
Using the integrated terminal

VS Code ships with a terminal panel built in (open it with Ctrl+backtick), and it automatically activates whichever virtual environment you selected as your interpreter. That means you can run scripts, install packages, and use the Python REPL without ever switching to a separate terminal application.

Bash
# run a script directly
python main.py

# start the interactive REPL
python

# install a package into the active environment
pip install requests

You can also run the currently open file with the green "Run" arrow in the top-right of the editor, or right-click anywhere in the file and choose "Run Python File in Terminal" — both do the same thing as typing the command yourself, just faster.

Structuring Your Project

Editor configuration solves how you write code; project structure solves how your code stays organized once there's more than one file. Settling on a consistent layout before a project grows saves you from a painful reorganization later.

my-project/
├── .venv/              # virtual environment (not committed to git)
├── src/
│   └── my_project/
│       ├── __init__.py
│       └── main.py
├── tests/
│   └── test_main.py
├── requirements.txt     # pinned dependencies
├── .gitignore
└── README.md
Tip
Start every new project with a consistent structure, even a small one: a project folder containing a virtual environment folder, a src (or package) folder for your actual code, a requirements.txt listing dependencies, and a README.md describing what the project does. It costs a couple of minutes up front and pays for itself the first time you revisit the project months later. The Project Structure page covers this layout — and how it scales up for larger applications — in more detail.

With your editor configured and a sensible folder layout as your default, you're ready to actually start writing Python without your tooling getting in the way. The next step is setting up the virtual environment itself, which is where we'll go next.