Python Dev Setup for University Coursework

Pylance (Official Extension by Microsoft)

Pylance works alongside the Python extension and provides the language intelligence layer. Install it for autocomplete, parameter hints, auto-imports, and go-to-definition across your project. The type checking mode (off / basic / strict) is set in Python > Analysis: Type Checking Mode. The basic level catches the common bugs without blocking progress on assignments that don't yet have full type annotations.

Key features: autocomplete, parameter suggestions, auto-imports, go-to-definition, find references, rename symbols across a project, hover documentation, and DocString generation.

Ruff (charliermarsh.ruff)

Ruff is a fast linter and formatter for Python written in Rust. A linter analyzes source code to flag potential bugs, unused imports, and style violations before the code runs. A formatter restructures code for consistency (indentation, spacing, line lengths, import ordering), following PEP 8 without changing behavior. The VS Code extension runs both on save, so the file is clean before you commit it.

Key features: style issue detection, unused import and variable detection, automatic formatting, import sorting, and quick fixes for common problems.

Turn on type checking

Pylance ships with three modes: off, basic, strict. Set Python > Analysis: Type Checking Mode to basic. Strict mode is satisfying once you trust your types; basic catches the bugs.

Drop this into .vscode/settings.json

{
  "python.defaultInterpreterPath": ".venv/bin/python",
  "python.terminal.activateEnvironment": true,
  "[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff",
    "editor.formatOnSave": true,
    "editor.codeActionsOnSave": {
      "source.fixAll.ruff": "explicit",
      "source.organizeImports.ruff": "explicit"
    }
  },
  "python.analysis.typeCheckingMode": "basic",
  "python.testing.pytestEnabled": true,
  "python.testing.pytestArgs": ["tests"],
  "files.exclude": {
    "**/__pycache__": true,
    "**/.pytest_cache": true
  }
}

On Windows, swap .venv/bin/python for .venv\Scripts\python.exe. Commit this file to the repo so anyone cloning the project gets the same editor behavior; the .gitignore snippet at the bottom keeps everything except settings.json out.

System Python
│
├── Project A (.venv)
│   ├── Flask 2.3
│   └── NumPy 1.26
│
└── Project B (.venv)
    ├── Flask 3.0
    └── Pandas 2.2

# Anywhere inside your assignment folder
cd ~/Courses/data100/hw3
python -m venv .venv

Create the venv from VS Code

Open your project folder in VS Code. Press Ctrl+Shift+P (Windows, Linux) or Cmd+Shift+P (macOS) to open the Command Palette. Type Create Environment and select it.

Select Quick Create to create a virtual environment for the project.

A .venv folder appears in the project root. Inside its bin/ folder (called Scripts/ on Windows), the environment contains its own Python executable and pip. The Python version used to create the environment is the version it runs on.

Select the interpreter in VS Code

Open the Command Palette and type Select Interpreter.

Pick the interpreter from the .venv folder created above.

At the bottom-right corner of VS Code, the Python indicator confirms the selected interpreter. Hover over it to see the full path. It points inside .venv/.

source .venv/bin/activate

# Prompt changes:
# (.venv) you@laptop hw3 %

# Confirm you are now inside the venv
which python
# /Users/you/Courses/data100/hw3/.venv/bin/python

# PowerShell
.venv\Scripts\Activate.ps1

# cmd.exe
.venv\Scripts\activate.bat

# Prompt changes:
# (.venv) PS C:\Courses\hw3>

# If PowerShell blocks the script:
# Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

Deactivate when you switch projects

deactivate

# Prompt returns to normal. The .venv folder
# stays on disk, ready for next time.

The deactivate command works on every OS once the venv is active. The prompt loses the (.venv) prefix and Python falls back to the system interpreter. Never commit the .venv folder to git; the .gitignore step at the bottom handles that.

# Install one package
pip install pandas

# Install several at known versions
pip install pandas==2.2.0 numpy==1.26.4 matplotlib==3.8.2

# Snapshot the current environment
pip freeze > requirements.txt

# Recreate the environment on another machine
pip install -r requirements.txt

Install packages from VS Code terminal

Open a terminal in VS Code by selecting Terminal > New Terminal from the menu bar.

With the virtual environment active, run pip to install packages. VS Code opens new terminals with the selected venv already activated when python.terminal.activateEnvironment is set to true in settings.json.

What a requirements.txt looks like

# requirements.txt
pandas==2.2.0
numpy==1.26.4
matplotlib==3.8.2
scikit-learn==1.4.0
pytest==8.0.0
ruff==0.3.4

Pin the exact version with ==. If your professor accepts >= ranges, fine, but the strict pin is what prevents the 11 p.m. surprise where pandas updates on the TA's machine and your DataFrame.append call breaks.

Save and restore the environment

# See all installed packages
pip list

# Save installed packages into requirements.txt
pip freeze > requirements.txt

# Install packages from requirements.txt
pip install -r requirements.txt

When sharing a project with a professor, classmate, or Gradescope autograder, the requirements.txt file is what lets them recreate the same environment. Code that runs locally but fails on the grading server is usually a missing or mismatched package.

requirements.txt vs pyproject.toml

requirements.txt is the right default for a single assignment. One file, one job: list packages. The pyproject.toml format wraps build metadata, entry points, and tool config; it shines for shippable libraries, not for hw3. Use pyproject.toml only if your course names it. The CS50P, DATA 100, and CSE 163 graders all read requirements.txt.

# Inside the venv
pip install pytest

# Suggested folder structure
hw3/
├── .venv/
├── src/
│   └── analysis.py
├── tests/
│   ├── __init__.py
│   ├── conftest.py
│   └── test_analysis.py
└── requirements.txt

A runnable tests/test_example.py

# tests/test_example.py
import pytest
from src.analysis import normalize_grade

def test_normalize_grade_handles_perfect_score():
    assert normalize_grade(100) == 1.0

def test_normalize_grade_handles_zero():
    assert normalize_grade(0) == 0.0

def test_normalize_grade_rejects_negative():
    with pytest.raises(ValueError):
        normalize_grade(-5)

@pytest.mark.parametrize(
    "raw,expected",
    [
        (75, 0.75),
        (50, 0.50),
        (88, 0.88),
    ],
)
def test_normalize_grade_scales_correctly(raw, expected):
    assert normalize_grade(raw) == expected

Linked-list example

Data structure assignments follow the same pattern. Here the project implements a linked list and the test file is named test_linked_list.py.

# tests/test_linked_list.py
from src.linked_list import LinkedList

def test_append():
    ll = LinkedList()
    ll.append(10)
    assert ll.head.data == 10

def test_length():
    ll = LinkedList()
    ll.append(1)
    ll.append(2)
    ll.append(3)
    assert ll.length() == 3

Run the tests

# Run all tests
pytest

# Verbose output
pytest -v

# Run a specific test file
pytest tests/test_linked_list.py

# Run a single test by name
pytest tests/test_linked_list.py::test_length

# Stop after first failure
pytest -x

# Show local variables when a test fails
pytest -l

conftest.py for shared fixtures

# tests/conftest.py
import pytest
import pandas as pd

@pytest.fixture
def sample_grades():
    return pd.DataFrame({
        "student_id": [1, 2, 3, 4],
        "raw_score": [88, 72, 95, 60],
    })

# In tests/test_analysis.py
def test_class_mean(sample_grades):
    assert sample_grades["raw_score"].mean() == 78.75

A fixture declared in conftest.py is auto-discovered by every test in the same folder. Use it for any object three or more tests want to share: a sample DataFrame, a temp file, a fake database session.

# With the venv activated
python main.py

Run from VS Code

VS Code adds a Run Python File button in the top-right corner of the editor. Clicking it runs the currently open file using the selected interpreter. When a virtual environment is active for the workspace, VS Code uses it automatically, no terminal activation needed.

# Inside the venv
pip install ruff

# Find style issues (does not edit files)
ruff check .

# Auto-fix what can be auto-fixed
ruff check . --fix

# Format every .py file
ruff format .

# Check formatting without rewriting
ruff format . --check

Formatting with ruff

Run ruff format . --diff first to preview what the formatter would change before it rewrites any files.

# Check to see what ruff would format
ruff format . --diff

# Format every .py file
ruff format .

Linting with ruff

# Find style issues (does not edit files)
ruff check .

# Auto-fix what can be auto-fixed
ruff check . --fix

Ruff does not automatically fix every issue. When a change is flagged as unsafe (for example, removing a variable that alters program behavior), ruff leaves the fix to you. To apply unsafe fixes explicitly:

# Fix everything, including unsafe items
ruff check . --fix --unsafe-fixes

Minimal ruff.toml at the project root

# ruff.toml
line-length = 100
target-version = "py312"

[lint]
select = [
    "E",    # pycodestyle errors
    "F",    # pyflakes
    "I",    # isort
    "B",    # flake8-bugbear
    "UP",   # pyupgrade
    "SIM",  # flake8-simplify
]
ignore = [
    "E501",  # line-too-long handled by formatter
]

[format]
quote-style = "double"
indent-style = "space"

target-version = "py312" tells ruff which interpreter to lint against. Set it to "py310" or "py311" if your course pins an older interpreter. Skip the ruff.toml entirely and the defaults still work fine; the file is for the moment a professor says 120-character lines and you need to widen line-length.