User Guide For Python With Examples

Python Basics You Actually Need to Know

Python is a programming language created by Guido van Rossum and first released in 1991. It runs on Windows, macOS, Linux, and just about anything else with an interpreter. The current stable version as of mid-2026 is Python 3.12, and honestly you should just stick with 3.10 or later at this point. Anything older and you will hit compatibility issues with modern libraries, which is more annoying than it sounds. The language is interpreted, which means code executes line by line rather than being compiled into machine code upfront. This makes debugging faster because you can run snippets without a full compile cycle. It also means Python is slower than compiled languages like C or Rust for compute-heavy tasks. If you are running numerical workloads, you will likely end up leaning on NumPy or Cython anyway. I learned that the hard way during a data processing job back in 2019 where my initial pure Python implementation took about 47 minutes for a dataset that NumPy reduced to roughly 90 seconds. No exaggeration.

User Guide For Python With Examples

Here is the thing most people skip when they start learning Python: indentation matters. It is not optional styling. Python uses whitespace to define code blocks, which means a single misplaced tab or inconsistent space count will throw an IndentationError before your code ever runs. I spent two full days debugging a script once only to find out a coworker's editor had inserted tabs while mine used spaces. Python 3 does not silently convert between the two. Set your editor to use 4 spaces per indent and never look back. Variables in Python do not have explicit types declared upfront. You assign a value and Python figures out the type at runtime. This is called dynamic typing. It is convenient until your function receives an unexpected type and crashes three levels deep in the call stack. Using type hints has become standard practice now, especially in larger codebases. A function signature like def calculate_total(items: list[float]) -> float: does not enforce anything at runtime but it helps static analysis tools catch mistakes before execution. Most teams I have worked with require type hints for production code.

Core Syntax and Common Patterns

Here is a minimal example of reading a CSV file and computing a basic aggregation: import csv
with open("sales.csv", newline="") as f:
  reader = csv.DictReader(f)
  total = sum(float(row["amount"]) for row in reader if row["status"] == "completed")
print(total) This reads a file, filters rows, sums values, and prints the result in four lines. It works. But there are edge cases worth noting. The with statement ensures the file handle closes even if an exception occurs during iteration. Without it, you risk leaving files open, which on some systems can lock the file and cause permission errors on subsequent runs. I ran into this exact problem when processing large batch files on a Windows server where the OS holds file locks aggressively.

List comprehensions are one of Python's most distinctive features. They are faster than equivalent for loops because the interpreter optimizes them internally. A comprehension like [x2 for x in range(1000000)] runs noticeably faster than the same operation written with an explicit loop and append. That said, readability matters too. If your comprehension spans more than two lines or nests three levels deep, break it into a regular function. Code that only one person on the team can parse is technically correct and practically useless.

Working with Modules and Packages

Python ships with a standard library that covers most everyday needs. You do not always need third-party packages. The json, os, datetime, re, and pathlib modules alone handle a surprising amount of real-world work. For anything beyond that, pip is the package installer. Use a virtual environment for every project. Running python -m venv venv creates an isolated environment so installed packages from one project do not collide with another. I once had a project break because Flask 2.x upgraded a dependency that conflicted with an existing Celery installation in the global Python environment. That cost me half a day. Virtual environments solve this by keeping dependencies scoped to individual projects. Dependency management is one area where Python still trails behind languages like Node.js or Go. There is no universal standard, though tools like poetry and uv are gaining traction. requirements.txt files are the old convention and they still work for simple projects. For anything with multiple dependencies and version constraints, invest time in learning poetry or at least pip-tools. Pinning exact versions with == instead of allowing flexibility with >= prevents what I call dependency drift, where code that runs fine on your machine breaks on CI because a transitive dependency updated unexpectedly.

Functions, Classes, and Practical Patterns

Functions in Python are first-class objects. You can pass them as arguments, return them from other functions, and assign them to variables. This enables patterns like decorators, which are widely used in web frameworks. A decorator wraps a function to add behavior without modifying the original code. Here is a practical example of a retry decorator: import functools
import time

def retry(max_attempts=3, delay=1):
  def decorator(func):
    @functools.wraps(func)
    def wrapper(*args, kwargs):
      for attempt in range(max_attempts):
        try:
          return func(*args, kwargs)
        except Exception as e:
          if attempt == max_attempts - 1:
            raise
          time.sleep(delay)
    return wrapper
  return decorator This is genuinely useful for API calls or database operations that fail intermittently due to network timeouts. The decorator retries up to three times with a one-second delay between attempts. I use something very close to this in production code for external service calls. The key detail is @functools.wraps(func), which preserves the original function's metadata. Without it, debuggers and documentation generators lose the function name and docstring, which makes troubleshooting significantly harder.

Classes in Python follow a different philosophy than strictly object-oriented languages. Everything is an object, but the language does not enforce encapsulation rigorously. There are no access modifiers like private or protected in the traditional sense. Prefixing an attribute with a single underscore is a convention that signals "do not access this directly," but it is not enforced. Double underscores trigger name mangling, which is stronger but still not true privacy. I have seen teams argue for hours about whether underscore conventions are worth the friction. They are not, but they are consistent across the ecosystem, so following them reduces confusion when reading other people's code.

Common Pitfalls and How to Avoid Them

Mutable default arguments is a classic Python gotcha. Consider this function: def append_item(item, lst=[]):
  lst.append(item)
  return lst Calling this multiple times without providing the second argument does not create a fresh list each time. It reuses the same list object that was created when the function was defined. The result is accumulated items across calls, which is almost never what you want. The fix is simple: use None as the default and create the list inside the function body. This pattern applies to any mutable default argument, including dictionaries and sets.

Another frequent issue is the interaction between global and local scope. Python resolves names using the LEGB rule: Local, Enclosing, Global, Built-in. If you assign to a variable inside a function without declaring it global, Python creates a local variable that shadows the global one. This causes subtle bugs where a variable appears unset because the assignment never reached the outer scope. I debugged this kind of issue in a logging utility where the log level was silently ignored because a function reassignment created a local variable that masked the module-level constant.

Tooling and Development Workflow

A decent development setup matters more than people admit. VS Code with the Python extension, ruff for linting, black for formatting, and pytest for testing covers the majority of needs. These tools integrate together well and save significant time on style disputes and trivial bugs. ruff is notably fast, running in milliseconds on large codebases compared to slower alternatives like flake8 which can take several seconds on projects with thousands of files. Testing is not optional. Even basic tests that verify input validation and expected output save hours of manual checking later. pytest is the default choice in the Python ecosystem. It supports fixtures, parameterization, and plugins out of the box. A simple test for the earlier CSV example would look like: def test_sum_completed_sales():
  data = "id,status,amount\\n1,completed,100\\n2,pending,50\\n3,completed,75"
  result = process_sales(data)
  assert result == 175

This runs in under a second and catches regressions immediately. Projects without tests tend to accumulate technical debt quickly. I have seen teams spend more time manually verifying functionality after changes than they would have spent writing automated tests initially. The ratio is usually about 4 to 1 in favor of testing for non-trivial code.

Where Python Falls Short

Python is not a universal solution. It struggles with CPU-bound concurrency due to the Global Interpreter Lock, which limits true parallel execution of Python bytecode in CPython. For genuine multi-core parallelism, you need the multiprocessing module or to offload to C extensions. Python's single-threaded execution model also means that CPU-intensive tasks will be slow regardless of how many cores your machine has. If your project is primarily computational, consider whether Python is the right tool or whether a compiled language or a specialized library would serve better. Memory usage is another concern. Python objects carry significant overhead compared to languages with manual memory management. A single integer in Python consumes roughly 28 bytes on a 64-bit system. Lists and dictionaries add even more. Processing datasets that exceed available RAM requires streaming or external tools like Dask or Polars. I encountered this limitation when a colleague attempted to load a 12 GB CSV into a pandas DataFrame on a machine with 16 GB of RAM, which left insufficient headroom for the OS and caused the process to be terminated by the kernel.

Next Steps

If you are starting out, focus on the standard library first before reaching for packages. Learn pathlib for file handling, collections for data structures, itertools for iteration patterns, and unittest or pytest for testing. Then move on to web frameworks like FastAPI or Django, data tools like pandas and NumPy, and automation libraries as your needs dictate. The ecosystem is large but you do not need to learn all of it at once. Most developers specialize in one or two domains and use Python well within that scope.