Python Tooling for C# Developers

Installing .NET gives you everything in one box. Installing Python gives you a box and a list of parts to assemble yourself. The runtime, the dependency sandbox, and the project tooling are separate concerns, maintained by separate communities, and chosen by the developer. That separation is the single biggest adjustment for someone coming from .NET.

This guide maps C#/.NET concepts to their closest Python equivalents and explains where the mental models diverge.

What Will Feel Familiar, What Will Not

Two mental model gaps deserve early attention.

Python’s tooling is layered, not bundled. The .NET SDK ships the runtime, project system, and package manager as one versioned artifact. Python keeps the interpreter, the virtual environment, and the project tooling as separate layers that can be mixed and matched. Multiple tools implement overlapping PEP standards, and package versioning practices are inconsistent across libraries, unlike NuGet’s reliable SemVer conventions.

There is no MSBuild equivalent. .NET projects have a declarative build system with targets, props files, and a standardized lifecycle (Restore → Build → Test → Publish). Python has no single build lifecycle. Libraries use build backends; applications often skip a build step entirely.

Python’s Three-Layer Model

The .NET SDK is one product. Python’s tooling splits into three layers: the interpreter (runtime), the virtual environment (dependency sandbox), and the project file (pyproject.toml).

Interpreter management. uv python install 3.12 downloads and manages Python versions, similar to installing a specific .NET SDK version. Unlike .NET, the interpreter does not include project tooling or an integrated SDK. CPython does bootstrap pip by default, but there is no all-in-one project system.

Virtual environments. A virtual environment is a filesystem-level isolation boundary for dependencies. It is attached to an existing interpreter; it does not choose or install one.

.NET restores packages into a global packages cache and uses assembly loading to resolve them per-project. Python uses a separate directory tree with its own site-packages folder. When using uv, virtual environments are created and managed automatically.

pyproject.toml. This file declares project metadata, dependencies, and tool configuration. It is lighter than .csproj (no XML, no MSBuild properties) but serves a similar role as the single source of truth for a project. Configuration for linting, formatting, and type checking also lives here, replacing the scattered .editorconfig and analyzer ruleset files common in .NET projects.

Python predates modern package management by over a decade, and different communities built solutions for each layer independently. PEP standards define the interfaces between layers, and multiple tools can implement them. This is why there are so many packaging tools.

The Daily Development Loop

Adding and Managing Dependencies

Adding a package looks familiar:

uv add requests

This is the equivalent of dotnet add package Newtonsoft.Json. The command updates pyproject.toml and writes a lock file (uv.lock) that pins exact versions for reproducible installs.

To install from the lock file (the equivalent of dotnet restore):

uv sync

One difference worth knowing: NuGet enforces semantic versioning conventions, and most .NET libraries follow them reliably. PyPI packages use version specifiers defined by PEP 440, but adherence to semantic versioning is uneven. Pinning via a lock file matters more in Python than it does in .NET, where version ranges tend to be safer.

Running Python Code and Import Semantics

Python has no user-invoked build step. Code runs directly from source (CPython compiles to bytecode internally and caches it in __pycache__):

uv run python main.py

There is no equivalent of dotnet build producing intermediate assemblies. The interpreter reads .py files and executes them.

Python has two ways to run code that have no C# parallel: python file.py runs a single script, while python -m package runs a package as a module, using Python’s import system to locate it. C# has no equivalent distinction because everything goes through dotnet run or the compiled assembly entry point.

For distributing command-line tools, Python uses console scripts (entry points declared in pyproject.toml) rather than a Program.cs with a Main method. When a package with console scripts is installed, the installer creates executable wrappers in the environment’s bin/ (or Scripts/) directory, which are available on PATH when the environment is active.

For active development on a library, an editable install links the source tree into the virtual environment so that code changes take effect without reinstalling. This is analogous to referencing a project directly in a .NET solution rather than consuming it as a NuGet package. Using a src/ layout for library code is a common convention that keeps the package importable only when properly installed.

Code Quality: Linting and Formatting

Ruff handles both linting and formatting in a single tool. It replaces what would be a combination of .NET analyzers, StyleCop, and dotnet format.

uv run ruff check .     # lint
uv run ruff format .    # format

Configuration often lives in pyproject.toml under [tool.ruff] (or in dedicated ruff.toml/.ruff.toml files), rather than .editorconfig or XML analyzer ruleset files.

Type Checking

C# is statically typed: the compiler rejects type errors before the program runs. Python is dynamically typed by default, with optional type annotations that external tools can check. Code with zero type annotations runs without issue.

Type checkers like mypy, pyright, and ty analyze annotations but are not part of the build process. They are separate tools, run separately, and can be adopted gradually. A project might start with no annotations, add them to critical modules first, and expand coverage over time.

C#’s nullable reference types (introduced in C# 8) are the closest analog to Python’s Optional type hints, but enforcement differs. In C#, the compiler warns about null dereferences when nullable analysis is enabled. In Python, a type checker flags similar issues, but only if annotations exist and the checker is configured to run.

Testing with pytest

pytest is the standard Python testing framework. It differs from xUnit/NUnit/MSTest in several ways.

Tests are plain functions, not methods on a class:

def test_addition():
    assert 1 + 1 == 2

There are no [Fact] or [Test] attributes. pytest discovers tests by naming convention: files named test_*.py and functions named test_* are collected automatically.

pytest fixtures replace the constructor injection and IClassFixture<T> patterns used in xUnit. A fixture is a function decorated with @pytest.fixture that provides test dependencies:

import pytest

@pytest.fixture
def db_connection():
    conn = create_test_database()
    yield conn
    conn.close()

def test_query(db_connection):
    result = db_connection.execute("SELECT 1")
    assert result is not None

The fixture name appears as a parameter to the test function, and pytest injects it automatically.

Packaging and Distribution

Library Packaging

Python libraries are distributed as wheels (prebuilt) and sdists (source distributions), published to PyPI. This is analogous to building a .nupkg and pushing it to NuGet.org.

uv build        # produces a wheel and sdist
uv publish      # uploads to PyPI

The build backend (declared in pyproject.toml) controls how the package is built, similar to how MSBuild targets control .NET package creation. PyPI is Python’s equivalent of NuGet.org.

Application Deployment

Most Python applications skip the build step entirely. There is no equivalent of dotnet publish producing a self-contained deployment or a single-file executable.

Instead, Python applications are deployed as source code plus a virtual environment, or inside containers. A typical deployment involves copying the source, running uv sync --frozen to reproduce the exact dependency set, and starting the application.

.NET’s self-contained single-file publish, which bundles the runtime and all dependencies into one artifact, has no standard Python equivalent. Tools like PyInstaller and Nuitka exist for this purpose, but they are not part of the standard workflow.

What Python Offers, and What You Will Miss

What Python has that .NET does not:

• REPL-driven development culture. .NET has C# scripting and F# Interactive, but Python’s ecosystem leans heavily on interactive workflows. IPython provides a rich interactive shell for experimenting with code. Jupyter notebooks extend this into a document format that mixes code, output, and prose, widely used for data analysis and prototyping.
• Multi-version testing orchestration. .NET has multi-targeting via TargetFrameworks, but Python’s tox and nox provide a different style of environment orchestration, running full test suites in isolated environments per Python version with a single command.

What C# developers will miss:

• Integrated debugging. Visual Studio’s debugging experience (breakpoints, watch windows, conditional breakpoints, Edit and Continue) is more polished than what Python IDEs offer. VS Code with the Python extension is capable but less seamless.
• NuGet’s versioning conventions. Most .NET libraries follow semantic versioning by convention. Python packages are less consistent in their versioning practices, making dependency updates riskier without a lock file.
• The all-in-one SDK. Installing .NET gives you everything. Python requires assembling a toolchain, though uv has closed much of this gap by combining interpreter management, virtual environments, and package management into a single tool.
• A standardized project system. MSBuild provides a declarative, extensible build system that handles multi-project solutions, build ordering, and output management. Python has no single universal equivalent, though tools like uv workspaces and Pants address parts of the monorepo story.