DEV Community: MEROLINE LIZLENT

Bitcoin Keys and Addresses

MEROLINE LIZLENT — Wed, 01 Jul 2026 14:41:42 +0000

Have you ever looked at one of these Bitcoin addresses, such as bc1q... or 1A1zP1... and wondered what it meant, or what was happening? We will go over how a private key becomes a public key, and how that public key becomes the address you use to send the money.

You can't access this feature without having a private key.

A Bitcoin private key is not magical; rather, it is a 256-bit random number. That's it. 32 bytes, 64 hex characters, selected preferably from an cryptographically-secure random number generator.

The Elliptic Curve Digital Signature Algorithm (ECDSA) is used on a curve that is known as secp256k1. Nearly any number of 256 bits is a valid private key under the parameters of this curve.

The downside: the security of your money is dependent on the randomness of that number. If your key is based on something that you can guess, such as your birthday, a memorable phrase, a weak PRNG, etc., then there are programs that can easily discover the key in mere seconds and your coins are lost. Bitcoin doesn't offer you a "forgot password" link, there's no second chance.

With ECDSA, it is possible to derive the public key from the private key, which means that the address is derived from the public key and that the possession of the private key is sufficient to get the address.

Displaying a Private key: WIF and WIF-compressed

A raw 32-byte number isn't fun to copy around, so Wallets show private keys as Wallet Import Format (WIF). WIF is simply Base58Check encoding (Base58 + version byte + 4-byte checksum) of the key bytes.

The compressed variant, WIF-C, puts an additional 0x01 byte in front of the encoding to indicate the public key is to be compressed (more on that below). Most modern wallets default to WIF-C as that is what helps maintain a smaller blockchain.

	Mainnet prefix	Testnet prefix
WIF	starts with `5`	starts with `9`
WIF-Compressed	starts with `K` or `L`	starts with `c`

Using a Python library such as bitcoinutils, generating both forms from the same secret exponent looks roughly like this:

from bitcoinutils.setup import setup
from bitcoinutils.keys import PrivateKey

setup('testnet')

priv = PrivateKey(secret_exponent=0x1a2b3c...)  # your 256-bit int
print(priv.to_wif(compressed=False))
print(priv.to_wif(compressed=True))

From private key to public key

Elliptic curve math allows you to easily convert from private to public, but not public to private (which would involve brute forcing the curve, a task that's too hard to do in the real world). The public key is obtained by multiplying the private key by a fixed point on the curve, G (the generator point):

P = k * G

P is a point on the curve with coordinates (x, y), each 32 bytes. Naively, that's 64 bytes for a public key, plus a 0x04 prefix to mark it as "uncompressed", 65 bytes total.

Because the curve is symmetric about the x-axis, for any given x there are only two possible y values (even or odd). So instead of storing the full y, we can store just a single bit indicating which one it is. That gives us the compressed public key: 33 bytes, prefixed with 0x02 (even y) or 0x03 (odd y).

pub = priv.get_public_key()
print(pub.to_hex())                  # compressed, 33 bytes
print(pub.to_hex(compressed=False))  # uncompressed, 65 bytes

Compressed keys are the default these days they're shorter, and Segregated Witness actually requires them.

From public key to address

One of the things that comes as a surprise to some new to Bitcoin is that you do not have to share your public key in order to receive funds. Address is a hash of the public key, which you share. There are some good reasons for this:

Addresses are shorter than public keys. The public key remains private until it's actually used to spend from that address, giving another (controversial, but true) degree of security against future cryptographic attacks.

The key to creating a legacy address:

publicKeyHash = RIPEMD160( SHA256( publicKey ) )
data = networkPrefix + publicKeyHash
checksum = first 4 bytes of SHA256( SHA256( data ) )
address = Base58CheckEncode( data + checksum )

That RIPEMD160(SHA256(x)) combo even has its own nickname: HASH160. You'll see it constantly when reading Bitcoin source code.

Type	Mainnet prefix	Testnet prefix
P2PKH (legacy)	`1`	`m` / `n`
P2SH	`3`	`2`
Native segwit (bech32)	`bc1`	`tb1`

addr = pub.get_address()
print(addr.to_string())

Because the hash of a compressed key differs from the hash of an uncompressed key, the same private key produces two different legacy addresses depending on which public-key form you hashed. Worth remembering if an old wallet ever "loses" a balance check the other form.

Segwit addresses: same idea, new encoding

Since the Segregated Witness upgrade, the recommended address format is native segwit, encoded with Bech32 instead of Base58Check. P2WPKH (witness pubkey hash) addresses on mainnet start with bc1, and tb1 on testnet. Under the hood it's still essentially "hash of the public key" just packaged differently, and cheaper to spend from thanks to the witness discount we'll get into in a later post.

There's also a "nested" variant, a segwit script wrapped inside a P2SH address created so older, segwit-unaware wallets could still send funds to segwit users. It looks just like a normal P2SH address (prefix 3 / 2) from the sender's point of view.

A quick word on wallets

Wallets generally fall into two camps:

Non-deterministic — a pile of independently generated random keys. Simple, but every new key means a fresh backup.
Deterministic (HD) — a single seed deterministically generates an entire tree of keys. Back up the seed once, and you can always regenerate every address you've ever used. This is what virtually every modern wallet does (BIP-32/39/44).

Vanity addresses, briefly

It's possible to grind random keys until the resulting address starts with a chosen string (1Kostas, for example). Each extra character multiplies the search space by roughly 58 (the size of the Base58 alphabet), so long vanity prefixes get expensive fast which is why dedicated vanity-mining pools exist, using clever elliptic-curve key addition so they never learn your final private key.

Wrapping up

The whole chain: random number - private key - public key via curve multiplication - address via hashing is what makes Bitcoin ownership verifiable without any central authority knowing who you are. Next time you generate an address in code, you'll know exactly what's happening at each step.

Go: The Language That Just Works

MEROLINE LIZLENT — Wed, 03 Jun 2026 11:46:23 +0000

Three engineers, Robert Griesemer, Rob Pike, and Ken Thompson, at Google in 2007 were tired.Three engineers at Google, Robert Griesemer, Rob Pike, and Ken Thompson were tired in 2007. Annoyed with waiting for C++ code to compile. Frustrated with the messiness that seeped into big code bases. Frustrated by the limitations of languages on their size and concurrency requirements of today's infrastructure.

So they built their own.

This is the bold idea that was born of Go: What if there was a language as fast as C, as readable as Python, and as concurrent as possible from the ground up? It was released as open source in 2009 and version 1.0 came in 2012 and has become one of the most impactful programming languages of the last 20 years.

Go's goal is to "provide for something that is easy to program but also efficient and safe like a statically typed, compiled language.

Go by the numbers

#8 on the TIOBE Index (2024), up from #14 in 2020
According to the Stack Overflow 2023 Developer Report, 13% of developers use Go on a regular basis.
Average salary is 70% higher than average Go developer salary.Median salary is 70% higher than the average Go developer's salary.

What makes Go genuinely different

Go is not just another C-family language. It involves a series of conscious and subjective decisions all of which are required to create something unusual: a language that can be used for small projects as well as infrastructure for the planet and remains the same in your head.

1. Concurrency as a first-class citizen

The Go runtime manages lightweight threads called goroutines. Conventional OS threads take 1MB+ per thread. Goroutines are born small, at just 2-8 KB — and can be started as needed; 100,000s can run on a single machine concurrently.

package main

import (
    "fmt"
    "sync"
)

// Fan-out: distribute work across goroutines
func processJobs(jobs <-chan string, wg *sync.WaitGroup) {
    defer wg.Done()
    for job := range jobs {
        fmt.Printf("Processing: %s\n", job)
    }
}

func main() {
    jobs := make(chan string, 100)
    var wg sync.WaitGroup

    // Spin up 10 workers — goroutines are cheap
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go processJobs(jobs, &wg)
    }

    jobs <- "build Docker image"
    jobs <- "run test suite"
    jobs <- "deploy to staging"
    close(jobs)

    wg.Wait()
}

Concurrent programs are easier to reason about and are much less prone to race conditions with the CSP (Communicating Sequential Processes) model, which is the model in which goroutines communicate through channels and not memory.

2. Blazing fast compilation

Go can take seconds to compile large codebases, instead of minutes. This isn't just a little convenience, this actually alters the way development feels. You have a very close feedback loop, no matter what the scale is. A Go build with over a thousand files, and it takes 3 seconds, is something of a miracle.

3. Static typing with type inference

The static type is able to detect bugs at compile-time, while the shorthand syntax := and interfaces make the code feel light.

// Explicit type declaration
var name string = "Gopher"

// Type inference — Go figures it out
name := "Gopher"

// Interfaces are satisfied implicitly (no 'implements' keyword)
type Writer interface {
    Write(p []byte) (n int, err error)
}

4. Garbage collected with low latency

Go's GC is optimized for latency operations. Modern versions are able to deliver sub-millisecond GC pauses (i.e. makes Java real-time systems feasible where it would have been a deal-breaker).

5. Batteries-included standard library

Go ships with an exceptionally rich standard library covering:

HTTP servers and clients (net/http)
JSON encoding/decoding (encoding/json)
Cryptography (crypto/tls, crypto/sha256)
Testing framework (testing)
Database interfaces (database/sql)
Templating (html/template, text/template)

All production-quality.
All without installing anything.

6. Single static binary output

Write-once-run-anywhere. Go generates a single binary file that can be executed without relying on any external runtimes. The deployment is just a copy of one file. The images of the containers shrink from gigabytes to megabytes.

# Cross-compile for Linux from macOS
GOOS=linux GOARCH=amd64 go build -o ./bin/myapp .

# Your entire app: one file
scp ./bin/myapp user@server:/opt/myapp

7. Enforced formatting

Your code is automatically formatted by gofmt. There is one style for all Go code, everywhere, all the time. No bikeshedding in PRs, no tab vs space debates, no style guide debates. The point of code reviews is logic and not looks.

8. Explicit error handling

Go treats errors as values, not exceptions. Every function returns an error that you must consciously handle.

file, err := os.Open("data.json")
if err != nil {
    return fmt.Errorf("opening data file: %w", err)
}
defer file.Close()

This is an interesting experience for developers coming from Python or JavaScript. It will be useful over time; in Go code bases, the failure modes will always be obvious in code. No unexpected path which catches you off guard in production.

Where Go dominates today

Go has not attempted to be all things to all people. It made deep inroads in certain areas of specialization and those areas happen to be the backbone of modern computing.

Go is the home of cloud infrastructure. The tools that power the internet are filled overwhelmingly with Go.The tools that power the internet Docker, Kubernetes, Terraform, Prometheus, etcd, CockroachDB, Caddy, Traefik, they are all written in Go. It's not a coincidence. Go's performance, binaries and concurrency are perfect for infrastructure software.

Another sweet spot is the use of Microservices and APIs. Go's net/http package is production-ready and its frameworks such as Gin, Echo, and Fiber simplify the creation of REST or gRPC applications quickly and efficiently. Handling 100K+ requests per second with regular hardware is nothing new for a Go HTTP server.

Go produces a single binary, it is ideal for distributing command-line tools. Install Go CLI: copy a file. No runtime requirements, no conflicts with other versions. This is why there are tons of DevOps tools that ship Go binaries.

Go vs. the competition

Go vs. Python

Go is 10-100 times faster in CPU-centric tasks and much more efficient in terms of memory and CPU resources. While Python is the go to language for data science and scripting, if it's services that must deal with heavy load, then Go will be a better option. Go's type system will also catch entire classes of bugs that Python will allow to enter production.

Go vs. Rust

Rust provides high degree of control and performance, but requires a very steep learning curve (borrow checker) and slower development velocity. When the performance of 95% of Rust is required with less than 10% of the learning curve, Go is the pragmatic option. Both are good — Go is the "get it shipped" language.

Go vs. Java / Node.js

It requires less memory than Java (no JVM overhead) and loads up in milliseconds, which is important for serverless and containerized deployments. Go's event-driven roots are shared by Node.js, which has difficulty with CPU-intensive tasks. Go is efficient with I/O and computation, without callbacks and async/await complexity.

Why Go is accelerating

The industry now has firmly moved into the containerized, distributed, cloud-native architecture. All the large cloud providers have had a lot of fun with Go. Major companies such as Google, Cloudflare, Uber, Twitch, Dropbox and Stripe have large Go code bases.

There's a flywheel effect with the language:

More infrastructure is written in Go
More engineers need to learn Go
More companies hire Go engineers
Even more infrastructure gets written in Go

Generics were introduced in Go 1.18 (2022) to address the longest-standing complaint in Go, and to start a new wave of library development. The system of modules developed. The toolchain sped up. Go in 2024 is a meaningful improvement not a complete overhaul of Go in 2018, and still retains all the original features.

The simplicity is not a weakness, it is the strength of Go. Better code by any person who can read it than by any genius that can write it, in large groups.

Who should learn Go?

Not all the tasks can be accomplished with Go. However, if your project involves any of these aspects, it is definitely worth considering:

Backend / API engineers building services that need to be fast, reliable, and maintainable by a team
DevOps / Platform engineers building tooling, CLIs, or anything touching Kubernetes or cloud infrastructure
Python developers hitting performance walls — Go is the natural next step when your service can't keep up with traffic
Anyone building distributed systems — Go's concurrency primitives and ecosystem are ideal for this domain

Where Go still falls short

Honestly addressing limits is important to a fair assessment.

A frequent criticism is the return of err if it is not nil dozens of times in a function. The explicitness is real useful, but there have been proposals for cleaner syntax for years.
Generics are not yet fully developed. Not all of them have been accepted into the standard library, and some patterns are not idiomatic in Go.
Go is not competitive in areas that demand maximum low-level control (embedded systems, OS kernels), vast mathematical computation (ML training) or rich GUI applications. Python is for data science, Rust is for bare metal and Go is for the middle layer.

Getting started

Go's onboarding is genuinely good. The official tour at go.dev/tour is interactive and covers the essentials in a few hours.

# Install Go (macOS with Homebrew)
brew install go

# Or download from go.dev/dl

# Create a new module
mkdir myapp && cd myapp
go mod init github.com/you/myapp

# Write your first program, then:
go run main.go        # run directly
go build -o ./bin/app # compile to binary
go test ./...         # run all tests

# Your binary: one file, zero dependencies
./bin/app

The Go community is friendly and the simplicity of the language makes other people's Go code really a fun to read. Begin with the tour and then read an article from a source you used for a project – Caddy or Prometheus are good sources.

The bottom line

In 2009, Go wagered that simplicity, speed and pragmatism would be more important than expressiveness. So, that gamble paid off big time 15 years ago. The language of the cloud-native revolution, and Docker and Kubernetes, is not going away… it's moving faster.

If you haven't taken a closer look at Go, you should now! It's easy to learn, it's got a great job market, and it's an ever more integral part of software development, solving problems that are increasingly relevant.

GitPython

MEROLINE LIZLENT — Wed, 13 May 2026 11:27:35 +0000

Have you ever written a deployment script with subprocess.run(["git", "pull"]) and felt like there just must be a better way? There is! GitPython provides you with a real Python API for doing anything Git can do: clone, commit, create branches, diffs, read history, etc.

Installation

pip install gitpython

GitPython assumes you have git installed on your system. It uses shelling out to git behind the scenes, translating into Python objects as cleanly as possible.

Opening a Repository

from git import Repo, InvalidGitRepositoryError

# Open an existing repo
repo = Repo("/path/to/your/project")

# Open the repo at the current working directory
repo = Repo(".")

# Open from any subdirectory (search_parent_directories=True)
repo = Repo(".", search_parent_directories=True)

# Safe opening with error handling
try:
    repo = Repo("/some/path")
except InvalidGitRepositoryError:
    print("Not a git repository")

Repository Basics

from git import Repo

repo = Repo(".")

# Basic info
print(repo.working_dir)       # /home/user/myproject
print(repo.git_dir)           # /home/user/myproject/.git
print(repo.is_dirty())        # True if there are uncommitted changes
print(repo.untracked_files)   # ['new_file.py', 'notes.txt']
print(repo.active_branch.name)  # main

# Check if repo has any commits
print(repo.head.is_valid())   # False if repo is empty

Cloning a Repository

from git import Repo

# Clone a public repo
repo = Repo.clone_from(
    "https://github.com/user/myproject.git",
    "/tmp/myproject"
)

# Clone a specific branch
repo = Repo.clone_from(
    "https://github.com/user/myproject.git",
    "/tmp/myproject",
    branch="develop"
)

# Clone with depth (shallow clone — faster for CI)
repo = Repo.clone_from(
    "https://github.com/user/myproject.git",
    "/tmp/myproject",
    depth=1
)

# Clone with SSH
repo = Repo.clone_from(
    "git@github.com:user/myproject.git",
    "/tmp/myproject"
)

Staging and Committing

from git import Repo
import os

repo = Repo(".")

# Stage specific files
repo.index.add(["README.md", "src/main.py"])

# Stage all changes (like `git add .`)
repo.git.add(A=True)

# Or using the index directly
changed_files = [item.a_path for item in repo.index.diff(None)]
untracked = repo.untracked_files
repo.index.add(changed_files + untracked)

# Commit
commit = repo.index.commit(
    "feat: add user authentication module",
    author_date="2024-01-15T10:00:00",
    commit_date="2024-01-15T10:00:00",
)
print(f"Committed: {commit.hexsha[:7]} — {commit.message.strip()}")

Commit with Custom Author

from git import Repo, Actor

repo = Repo(".")

author = Actor("Alice", "alice@example.com")
committer = Actor("CI Bot", "ci@example.com")

repo.index.add(["deploy.yaml"])
repo.index.commit(
    "chore: update deployment config",
    author=author,
    committer=committer,
)

Branches

from git import Repo

repo = Repo(".")

# List all branches
for branch in repo.branches:
    print(branch.name)

# List remote branches
for ref in repo.remotes.origin.refs:
    print(ref.name)

# Create a new branch
new_branch = repo.create_head("feature/login")

# Switch to a branch (checkout)
new_branch.checkout()

# Or one-liner
repo.git.checkout("-b", "feature/signup")

# Delete a branch
repo.delete_head("feature/old-stuff", force=True)

# Check current branch
print(repo.active_branch.name)  # feature/login

Working with Remotes

from git import Repo

repo = Repo(".")

# List remotes
for remote in repo.remotes:
    print(f"{remote.name}: {remote.url}")

# Fetch
repo.remotes.origin.fetch()

# Pull
repo.remotes.origin.pull()

# Push
repo.remotes.origin.push()

# Push a specific branch
repo.remotes.origin.push(refspec="feature/login:feature/login")

# Add a new remote
repo.create_remote("upstream", "https://github.com/original/repo.git")

# Remove a remote
repo.delete_remote("upstream")

Reading Commit History

from git import Repo

repo = Repo(".")

# Iterate over commit history
for commit in repo.iter_commits("main", max_count=10):
    print(f"{commit.hexsha[:7]}  {commit.authored_datetime}  {commit.author.name}")
    print(f"  {commit.message.strip()}")
    print()

a3f1c22  2024-01-15 10:30:00  Alice
  feat: add payment gateway

7b2d891  2024-01-14 16:45:00  Bob
  fix: correct validation logic

Filter by Author, Path, or Date

from datetime import datetime

# Commits by a specific author
for commit in repo.iter_commits("main", author="Alice"):
    print(commit.message.strip())

# Commits touching a specific file
for commit in repo.iter_commits("main", paths="src/auth.py"):
    print(f"{commit.hexsha[:7]} {commit.message.strip()}")

# Commits since a date
since = datetime(2024, 1, 1)
for commit in repo.iter_commits("main"):
    if commit.authored_datetime.replace(tzinfo=None) < since:
        break
    print(commit.message.strip())

Diffs: What Changed?

from git import Repo

repo = Repo(".")

# Diff between working directory and index (unstaged changes)
for diff in repo.index.diff(None):
    print(f"Modified: {diff.a_path}")

# Diff between index and HEAD (staged changes)
for diff in repo.index.diff("HEAD"):
    print(f"Staged: {diff.a_path}")

# Diff between two commits
commits = list(repo.iter_commits("main", max_count=2))
diffs = commits[1].diff(commits[0])

for diff in diffs:
    print(f"Changed: {diff.a_path}")
    if diff.diff:
        print(diff.diff.decode("utf-8"))

Reading File Contents from Git

You can read file contents from any commit without touching the filesystem:

from git import Repo

repo = Repo(".")

# Read a file at HEAD
blob = repo.head.commit.tree["README.md"]
content = blob.data_stream.read().decode("utf-8")
print(content)

# Read from a specific commit
commit = repo.commit("a3f1c22")
blob = commit.tree["src/main.py"]
print(blob.data_stream.read().decode("utf-8"))

# Navigate into subdirectories
blob = repo.head.commit.tree["src"]["auth"]["jwt.py"]
print(blob.data_stream.read().decode("utf-8"))

Submodules

from git import Repo

repo = Repo(".")

# List submodules
for submodule in repo.submodules:
    print(f"{submodule.name}: {submodule.url}")

# Add a submodule
repo.create_submodule("mylib", "libs/mylib", url="https://github.com/user/mylib.git")

# Update all submodules
for submodule in repo.submodules:
    submodule.update(init=True)

Real-World Patterns

Auto-Commit Changed Files

from git import Repo, Actor
from datetime import datetime

def auto_commit(repo_path: str, message: str = None):
    repo = Repo(repo_path)

    if not repo.is_dirty(untracked_files=True):
        print("Nothing to commit")
        return

    # Stage everything
    repo.git.add(A=True)

    msg = message or f"auto: update {datetime.now().strftime('%Y-%m-%d %H:%M')}"
    commit = repo.index.commit(msg, author=Actor("AutoBot", "bot@example.com"))
    print(f"Committed: {commit.hexsha[:7]}")
    return commit

auto_commit(".", "chore: automated sync")

Generate a Changelog

from git import Repo
from collections import defaultdict

def generate_changelog(repo_path: str, from_tag: str, to_tag: str = "HEAD") -> str:
    repo = Repo(repo_path)
    commits = list(repo.iter_commits(f"{from_tag}..{to_tag}"))

    categories = defaultdict(list)
    for commit in commits:
        msg = commit.message.strip().split("\n")[0]
        if msg.startswith("feat"):
            categories["Features"].append(msg)
        elif msg.startswith("fix"):
            categories["Bug Fixes"].append(msg)
        elif msg.startswith("chore") or msg.startswith("ci"):
            categories["Maintenance"].append(msg)
        else:
            categories["Other"].append(msg)

    lines = [f"# Changelog: {from_tag} → {to_tag}\n"]
    for category, items in categories.items():
        lines.append(f"\n## {category}")
        for item in items:
            lines.append(f"- {item}")

    return "\n".join(lines)

print(generate_changelog(".", "v1.0.0", "v1.1.0"))

Find Who Last Modified a Line (git blame)

from git import Repo

def blame_file(repo_path: str, file_path: str):
    repo = Repo(repo_path)
    blame = repo.blame("HEAD", file_path)

    for commit, lines in blame:
        for line in lines:
            print(f"{commit.hexsha[:7]}  {commit.author.name:<20}  {line.decode('utf-8')}", end="")

blame_file(".", "src/auth.py")

Check if Branch Is Behind Remote

from git import Repo

def check_sync_status(repo_path: str):
    repo = Repo(repo_path)
    origin = repo.remotes.origin
    origin.fetch()

    branch = repo.active_branch
    tracking = branch.tracking_branch()

    if tracking is None:
        print("Branch has no remote tracking")
        return

    ahead = list(repo.iter_commits(f"{tracking}..{branch}"))
    behind = list(repo.iter_commits(f"{branch}..{tracking}"))

    print(f"Branch '{branch.name}':")
    print(f"  Ahead by:  {len(ahead)} commit(s)")
    print(f"  Behind by: {len(behind)} commit(s)")

check_sync_status(".")

Using the Raw Git Interface

For executing Git commands not exposed through GitPython's API, call repo.git with any git command you want to run:

from git import Repo

repo = Repo(".")

# Any git command as a method call
output = repo.git.log("--oneline", "-5")
print(output)

# git stash
repo.git.stash("save", "work in progress")
repo.git.stash("pop")

# git cherry-pick
repo.git.cherry_pick("a3f1c22")

# git rebase
repo.git.rebase("main")

Summarizing

GitPython elevates Git from a shell-scriptable command line tool to a fully fledged Python object. Writing deployment tools, code analysis apps, changelog generators or scripts to massage repository data? GitPython has you covered. No more cutting and parsing subprocess output.

Ideally suited to automation: anything you would normally do by hand, with a series of git commands, can be turned into a neat, testable Python function.

Pydantic v2: The Data Validation Library That Makes Python Feel Type-Safe

MEROLINE LIZLENT — Wed, 13 May 2026 10:44:41 +0000

Pydantic is a full data validation, serialization, and settings management library. And with v2 which has been rewritten in Rust, is blazingly fast. This article covers everything from the basics to the advanced patterns that will change how you write Python.

What Is Pydantic?

Pydantic lets you define data schemas using Python type hints and then validates data against those schemas at runtime. When validation fails, you get clear, structured error messages not cryptic KeyError or AttributeError exceptions buried in your business logic.

pip install pydantic
pip install "pydantic[email]"  # for EmailStr and other extras

The Basics: BaseModel

from pydantic import BaseModel

class User(BaseModel):
    id: int
    name: str
    email: str
    is_active: bool = True

# Valid data
user = User(id=1, name="Alice", email="alice@example.com")
print(user.id)        # 1
print(user.is_active) # True (default)

# Pydantic converts compatible types
user2 = User(id="42", name="Bob", email="bob@example.com")
print(type(user2.id))  # <class 'int'> — "42" was coerced to 42

Type coercion is one of Pydantic's most useful behaviors. It tries to convert compatible values rather than failing immediately.

Validation

from pydantic import BaseModel, ValidationError

class Product(BaseModel):
    name: str
    price: float
    quantity: int

try:
    p = Product(name="Widget", price="not_a_number", quantity=10)
except ValidationError as e:
    print(e.json())

Output:

[
  {
    "type": "float_parsing",
    "loc": ["price"],
    "msg": "Input should be a valid number, unable to parse string as a number",
    "input": "not_a_number",
    "url": "https://errors.pydantic.dev/2.x/v/float_parsing"
  }
]

Structured, machine-readable errors with field location, error type, and the offending input.

Field: Fine-Grained Validation

The Field function lets you add constraints, defaults, aliases, and metadata to individual fields.

from pydantic import BaseModel, Field
from typing import Optional

class Article(BaseModel):
    title: "str = Field(..., min_length=3, max_length=200)"
    slug: str = Field(..., pattern=r"^[a-z0-9-]+$")
    body: str = Field(..., min_length=10)
    views: int = Field(default=0, ge=0)
    rating: float = Field(default=5.0, ge=1.0, le=5.0)
    tags: list[str] = Field(default_factory=list, max_length=10)
    author_id: Optional[int] = Field(None, description="Foreign key to users table")

... (Ellipsis) means the field is required. Common constraints:

min_length / max_length — for strings and lists
ge / le / gt / lt — numeric bounds (≥, ≤, >, <)
pattern — regex validation for strings
default_factory — callable that produces the default (use this instead of default=[])

Custom Validators

Field Validators

from pydantic import BaseModel, field_validator

class UserRegistration(BaseModel):
    username: str
    password: str
    confirm_password: str

    @field_validator("username")
    @classmethod
    def username_must_be_alphanumeric(cls, v: str) -> str:
        if not v.isalnum():
            raise ValueError("Username must contain only letters and numbers")
        return v.lower()  # normalize to lowercase

    @field_validator("password")
    @classmethod
    def password_strength(cls, v: str) -> str:
        if len(v) < 8:
            raise ValueError("Password must be at least 8 characters")
        if not any(c.isupper() for c in v):
            raise ValueError("Password must contain at least one uppercase letter")
        if not any(c.isdigit() for c in v):
            raise ValueError("Password must contain at least one digit")
        return v

Model Validators (Cross-Field Validation)

Sometimes you need to validate multiple fields together. Use @model_validator:

from pydantic import BaseModel, model_validator

class PasswordReset(BaseModel):
    password: str
    confirm_password: str

    @model_validator(mode="after")
    def passwords_must_match(self) -> "PasswordReset":
        if self.password != self.confirm_password:
            raise ValueError("Passwords do not match")
        return self

class DateRange(BaseModel):
    start_date: date
    end_date: date

    @model_validator(mode="after")
    def end_must_be_after_start(self) -> "DateRange":
        if self.end_date <= self.start_date:
            raise ValueError("end_date must be after start_date")
        return self

Types That Do the Heavy Lifting

Pydantic ships with a rich set of built-in types that handle common validation patterns:

from pydantic import BaseModel, EmailStr, HttpUrl, AnyUrl
from pydantic import IPvAnyAddress, SecretStr, PositiveInt, NegativeFloat
from datetime import datetime
from uuid import UUID

class RichModel(BaseModel):
    # Validated email address
    email: EmailStr

    # Validated URLs
    website: HttpUrl
    profile_picture: AnyUrl

    # UUID (accepts strings and UUID objects)
    user_id: UUID

    # Hides value in repr and logs — great for passwords/tokens
    api_key: SecretStr

    # Type shortcuts
    age: PositiveInt          # int > 0
    temperature: NegativeFloat  # float < 0

    # IP address (v4 or v6)
    ip_address: IPvAnyAddress

    # Datetime parsing from strings, timestamps, etc.
    created_at: datetime

data = RichModel(
    email="user@example.com",
    website="https://example.com",
    profile_picture="s3://bucket/image.png",
    user_id="550e8400-e29b-41d4-a716-446655440000",
    api_key="super-secret-key",
    age=25,
    temperature=-3.5,
    ip_address="192.168.1.1",
    created_at="2024-01-15T10:30:00Z",
)

print(data.api_key)          # **********  (hidden!)
print(data.api_key.get_secret_value())  # super-secret-key

Nested Models and Composition

Pydantic models compose naturally:

from pydantic import BaseModel
from typing import Optional

class Address(BaseModel):
    street: str
    city: str
    country: str
    postal_code: Optional[str] = None

class Company(BaseModel):
    name: str
    address: Address

class Employee(BaseModel):
    name: str
    company: Company
    work_address: Optional[Address] = None

# Nested dict input works seamlessly
data = {
    "name": "Alice",
    "company": {
        "name": "Acme Corp",
        "address": {
            "street": "123 Main St",
            "city": "Nairobi",
            "country": "Kenya"
        }
    }
}

employee = Employee(**data)
print(employee.company.address.city)  # Nairobi

Validation cascades through all nested models automatically.

Generics: Reusable Response Wrappers

One of Pydantic's most useful patterns for APIs is a generic response wrapper:

from pydantic import BaseModel
from typing import Generic, TypeVar, Optional, List

T = TypeVar("T")

class PaginatedResponse(BaseModel, Generic[T]):
    items: List[T]
    total: int
    page: int
    per_page: int
    has_next: bool

class APIResponse(BaseModel, Generic[T]):
    success: bool
    data: Optional[T] = None
    error: Optional[str] = None

class UserOut(BaseModel):
    id: int
    name: str
    email: str

# Usage
response = APIResponse[UserOut](
    success=True,
    data=UserOut(id=1, name="Alice", email="alice@example.com")
)

paginated = PaginatedResponse[UserOut](
    items=[UserOut(id=1, name="Alice", email="alice@example.com")],
    total=1,
    page=1,
    per_page=10,
    has_next=False,
)

In FastAPI, these generics show up correctly in the OpenAPI schema too.

Serialization: model_dump and model_dump_json

from pydantic import BaseModel, Field
from datetime import datetime

class Event(BaseModel):
    event_id: int = Field(alias="eventId")
    title: str
    created_at: datetime

event = Event(eventId=1, title="Conference", created_at=datetime.now())

# Convert to dict
print(event.model_dump())
# {'event_id': 1, 'title': 'Conference', 'created_at': datetime(...)}

# Use the alias in output
print(event.model_dump(by_alias=True))
# {'eventId': 1, 'title': 'Conference', 'created_at': datetime(...)}

# Exclude fields
print(event.model_dump(exclude={"created_at"}))

# Include only specific fields
print(event.model_dump(include={"title", "event_id"}))

# Serialize to JSON string (fast Rust-based serializer)
print(event.model_dump_json())

Aliases: Bridging Different Naming Conventions

APIs often use camelCase while Python uses snake_case. Pydantic handles this elegantly:

from pydantic import BaseModel, Field
from pydantic.alias_generators import to_camel

class UserProfile(BaseModel):
    model_config = {"alias_generator": to_camel, "populate_by_name": True}

    first_name: str
    last_name: str
    phone_number: str

# Accept camelCase input (from a JS frontend)
profile = UserProfile(firstName="Alice", lastName="Smith", phoneNumber="+254712345678")
print(profile.first_name)  # Alice

# Output camelCase (for a JS frontend)
print(profile.model_dump(by_alias=True))
# {'firstName': 'Meroline', 'lastName': 'Lizlent', 'phoneNumber': '+254712345678'}

Model Config: Customizing Behavior

model_config controls how your model behaves:

from pydantic import BaseModel, ConfigDict

class StrictUser(BaseModel):
    model_config = ConfigDict(
        # Reject extra fields instead of ignoring them
        extra="forbid",

        # Don't coerce types — "42" won't become 42
        strict=True,

        # Validate default values too
        validate_default=True,

        # Allow population by field name even when alias is set
        populate_by_name=True,

        # Freeze the model (make it immutable/hashable)
        frozen=True,
    )

    id: int
    name: str

Common extra options:

"ignore" (default) — silently discard extra fields
"forbid" — raise a validation error if extra fields are present
"allow" — keep extra fields in the model

Pydantic Settings: Managing Configuration

One of Pydantic's killer features for production apps: pydantic-settings for environment variable management.

pip install pydantic-settings

from pydantic import Field
from pydantic_settings import BaseSettings, SettingsConfigDict

class Settings(BaseSettings):
    model_config = SettingsConfigDict(
        env_file=".env",
        env_file_encoding="utf-8",
        case_sensitive=False,
    )

    # Required — will raise error if not set
    database_url: str
    secret_key: str

    # Optional with defaults
    debug: bool = False
    allowed_hosts: list[str] = ["localhost"]
    max_connections: int = Field(default=10, ge=1, le=100)
    app_name: str = "My App"

# Loads from environment variables and .env file automatically
settings = Settings()
print(settings.database_url)

Your .env:

DATABASE_URL=postgresql://user:pass@localhost/mydb
SECRET_KEY=your-secret-key-here
DEBUG=true
MAX_CONNECTIONS=20

Use it with a singleton pattern in FastAPI:

from functools import lru_cache

@lru_cache
def get_settings() -> Settings:
    return Settings()

# In your FastAPI routes
from fastapi import Depends

@app.get("/info")
def app_info(settings: Settings = Depends(get_settings)):
    return {"app": settings.app_name, "debug": settings.debug}

Computed Fields

Need a field derived from other fields?

from pydantic import BaseModel, computed_field

class Rectangle(BaseModel):
    width: float
    height: float

    @computed_field
    @property
    def area(self) -> float:
        return self.width * self.height

    @computed_field
    @property
    def perimeter(self) -> float:
        return 2 * (self.width + self.height)

r = Rectangle(width=5.0, height=3.0)
print(r.area)       # 15.0
print(r.model_dump())  # includes 'area' and 'perimeter'

Discriminated Unions: Polymorphic Models

When you have multiple model types that share a field used to distinguish them:

from pydantic import BaseModel
from typing import Literal, Union, Annotated
from pydantic import Field

class CreditCardPayment(BaseModel):
    payment_type: Literal["credit_card"]
    card_number: str
    expiry: str
    cvv: str

class BankTransferPayment(BaseModel):
    payment_type: Literal["bank_transfer"]
    account_number: str
    routing_number: str

class MpesaPayment(BaseModel):
    payment_type: Literal["mpesa"]
    phone_number: str
    transaction_id: str

Payment = Annotated[
    Union[CreditCardPayment, BankTransferPayment, MpesaPayment],
    Field(discriminator="payment_type")
]

class Order(BaseModel):
    order_id: int
    amount: float
    payment: Payment

# Pydantic knows exactly which model to use based on payment_type
order = Order(
    order_id=1,
    amount=99.99,
    payment={"payment_type": "mpesa", "phone_number": "+254712345678", "transaction_id": "MPX123"}
)
print(type(order.payment))  # <class 'MpesaPayment'>

Performance: Pydantic v2 Is Fast

Pydantic v2 was rewritten in Rust and is dramatically faster than v1:

Operation	v1	v2
Model validation	baseline	~5-50x faster
JSON serialization	baseline	~10x faster
Schema generation	baseline	~2-5x faster

For high-throughput APIs handling thousands of requests per second, this matters.

You can also pre-compile validators for repeated use:

from pydantic import TypeAdapter

# Validate a list of items without defining a full model
adapter = TypeAdapter(list[int])
result = adapter.validate_python(["1", "2", "3"])
print(result)  # [1, 2, 3]

# Or validate JSON directly (fast path)
result = adapter.validate_json("[1, 2, 3]")

Common Pitfalls

Mutable defaults

# BAD — shared mutable default (classic Python bug)
class Model(BaseModel):
    tags: list = []  # all instances share the same list!

# GOOD
class Model(BaseModel):
    tags: list[str] = Field(default_factory=list)

Modifying a model directly

user = User(id=1, name="Alice")
user.name = "Bob"  # This works but bypasses validation in some contexts

# For truly immutable models:
class User(BaseModel):
    model_config = ConfigDict(frozen=True)
    id: int
    name: str

The dict returned by model_dump() contains the same objects. If you need a deep copy, use model.model_copy(deep=True).

Summary

Pydantic is one of those libraries that, once you learn it properly, changes how you think about data in Python. It brings structure, validation, and type safety to a language that's historically been loose about all three.

The patterns covered here; Field constraints, custom validators, generics, discriminated unions, Settings management are production patterns used in real systems.

JWT Authentication

MEROLINE LIZLENT — Wed, 13 May 2026 08:41:58 +0000

JSON Web Tokens are everywhere. They're the de facto standard for stateless API authentication and they're also one of the most misunderstood and misimplemented security mechanisms in web development.

This article covers JWT from first principles, including common mistakes that create security vulnerabilities, and walks through a complete, production-ready implementation in Python with FastAPI.

What Is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe token that encodes a JSON payload and optionally signs or encrypts it. It's used to transmit verified claims between parties most commonly, "this user is authenticated and has these permissions."

A JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6MTcxNjY1MDAwMH0.3rW7TE8iCCiLBOBs6nLBpWxXuV3zqkL9mYpC2HBkd4s

It's three Base64URL-encoded segments joined by dots:

HEADER.PAYLOAD.SIGNATURE

Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Specifies the algorithm used to sign the token.

Payload (Claims)

{
  "sub": "user_123",
  "name": "Alice",
  "role": "admin",
  "iat": 1716563600,
  "exp": 1716650000
}

Standard claims include:

sub — subject (typically a user ID)
iat — issued at
exp — expiry
nbf — not before
iss — issuer
aud — audience

The payload is NOT encrypted by default. It's only Base64-encoded, which is trivially reversible. Never store sensitive data (passwords, credit card numbers) in a JWT payload.

Signature

HMACSHA256(
  base64url(header) + "." + base64url(payload),
  secret_key
)

The signature is what makes JWTs trustworthy. The server verifies that nobody tampered with the payload by recomputing the signature and comparing it.

How JWT Authentication Works

1. User logs in with credentials (username + password)
2. Server validates credentials, issues a signed JWT
3. Client stores the JWT (usually in memory or localStorage)
4. Client sends JWT in the Authorization header on subsequent requests:
   Authorization: Bearer <token>
5. Server verifies the signature and extracts the claims
6. No database lookup required — the token is self-contained

This is what "stateless" authentication means: the server doesn't need to store session data. All the information is in the token itself.

JWT vs Sessions: When to Use Each

	JWT	Sessions
Storage	Client-side	Server-side
Scalability	Easy (no shared state)	Harder (needs shared session store)
Revocation	Hard (tokens are valid until expiry)	Easy (delete from store)
Size	Larger (header on every request)	Small (just a session ID)
Best for	Stateless APIs, microservices	Traditional web apps with logout

JWTs are great for APIs. For apps where you need instant revocation (logout that actually works), session-based auth or short-lived JWTs + refresh tokens is better.

Implementation: FastAPI + JWT

Dependencies

pip install fastapi uvicorn python-jose[cryptography] passlib[bcrypt] python-multipart

python-jose: JWT encoding/decoding
passlib: Password hashing with bcrypt

Project Structure

app/
├── main.py
├── auth.py        # JWT logic
├── models.py      # Pydantic models
└── database.py    # Fake DB for demo

`auth.py` — Core JWT Logic

from datetime import datetime, timedelta, timezone
from typing import Optional
from jose import JWTError, jwt
from passlib.context import CryptContext

# Configuration — store these in environment variables in production!
SECRET_KEY = "your-super-secret-key-change-this-in-production"
ALGORITHM = "HS256"
ACCESS_TOKEN_EXPIRE_MINUTES = 30
REFRESH_TOKEN_EXPIRE_DAYS = 7

pwd_context = CryptContext(schemes=["bcrypt"], deprecated="auto")

def hash_password(password: str) -> str:
    return pwd_context.hash(password)

def verify_password(plain_password: str, hashed_password: str) -> bool:
    return pwd_context.verify(plain_password, hashed_password)

def create_access_token(data: dict, expires_delta: Optional[timedelta] = None) -> str:
    to_encode = data.copy()
    expire = datetime.now(timezone.utc) + (
        expires_delta or timedelta(minutes=ACCESS_TOKEN_EXPIRE_MINUTES)
    )
    to_encode.update({"exp": expire, "type": "access"})
    return jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)

def create_refresh_token(data: dict) -> str:
    to_encode = data.copy()
    expire = datetime.now(timezone.utc) + timedelta(days=REFRESH_TOKEN_EXPIRE_DAYS)
    to_encode.update({"exp": expire, "type": "refresh"})
    return jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)

def decode_token(token: str) -> dict:
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
        return payload
    except JWTError:
        return None

`models.py`

from pydantic import BaseModel
from typing import Optional

class UserLogin(BaseModel):
    username: str
    password: str

class Token(BaseModel):
    access_token: str
    refresh_token: str
    token_type: str = "bearer"

class TokenData(BaseModel):
    user_id: Optional[str] = None
    role: Optional[str] = None

`database.py` (Mock DB)

from auth import hash_password

# In production, replace with real database queries
FAKE_USERS_DB = {
    "alice": {
        "id": "user_001",
        "username": "alice",
        "hashed_password": hash_password("secret123"),
        "role": "admin",
        "is_active": True,
    },
    "bob": {
        "id": "user_002",
        "username": "bob",
        "hashed_password": hash_password("password456"),
        "role": "user",
        "is_active": True,
    },
}

def get_user(username: str):
    return FAKE_USERS_DB.get(username)

`main.py` — The Full Application

from fastapi import FastAPI, Depends, HTTPException, status
from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
from auth import (
    verify_password, create_access_token, create_refresh_token, decode_token
)
from database import get_user
from models import UserLogin, Token

app = FastAPI(title="JWT Auth Demo")
security = HTTPBearer()

# Authentication 
@app.post("/auth/login", response_model=Token)
def login(credentials: UserLogin):
    user = get_user(credentials.username)

    if not user or not verify_password(credentials.password, user["hashed_password"]):
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Invalid username or password",
            headers={"WWW-Authenticate": "Bearer"},
        )

    if not user["is_active"]:
        raise HTTPException(status_code=400, detail="Inactive user")

    token_data = {"sub": user["id"], "username": user["username"], "role": user["role"]}

    return Token(
        access_token=create_access_token(token_data),
        refresh_token=create_refresh_token(token_data),
    )

@app.post("/auth/refresh", response_model=Token)
def refresh_token(credentials: HTTPAuthorizationCredentials = Depends(security)):
    payload = decode_token(credentials.credentials)

    if not payload or payload.get("type") != "refresh":
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Invalid or expired refresh token",
        )

    token_data = {
        "sub": payload["sub"],
        "username": payload["username"],
        "role": payload["role"],
    }

    return Token(
        access_token=create_access_token(token_data),
        refresh_token=create_refresh_token(token_data),
    )

# Dependency: Get Current User 

def get_current_user(credentials: HTTPAuthorizationCredentials = Depends(security)):
    payload = decode_token(credentials.credentials)

    if not payload or payload.get("type") != "access":
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Could not validate credentials",
            headers={"WWW-Authenticate": "Bearer"},
        )

    user = get_user(payload.get("username"))
    if not user:
        raise HTTPException(status_code=404, detail="User not found")

    return user

def require_admin(current_user: dict = Depends(get_current_user)):
    if current_user["role"] != "admin":
        raise HTTPException(
            status_code=status.HTTP_403_FORBIDDEN,
            detail="Admin access required",
        )
    return current_user

# Protected Routes 

@app.get("/me")
def get_profile(current_user: dict = Depends(get_current_user)):
    return {
        "id": current_user["id"],
        "username": current_user["username"],
        "role": current_user["role"],
    }

@app.get("/admin/dashboard")
def admin_dashboard(admin: dict = Depends(require_admin)):
    return {"message": f"Welcome, {admin['username']}. Here's the admin dashboard."}

@app.get("/public")
def public_route():
    return {"message": "This route requires no authentication"}

Testing It

uvicorn main:app --reload

curl -X POST http://localhost:8000/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username": "alice", "password": "secret123"}'

Use the access token:

curl http://localhost:8000/me \
  -H "Authorization: Bearer <your_access_token>"

Common Security Mistakes and How to Avoid Them

Using a weak or hardcoded secret key

# BAD
SECRET_KEY = "secret"

# GOOD — generate with: python -c "import secrets; print(secrets.token_hex(32))"
SECRET_KEY = os.environ["JWT_SECRET_KEY"]

Using the `none` algorithm

Some early JWT libraries had a bug where alg: none would skip signature verification. Always explicitly specify allowed algorithms:

jwt.decode(token, SECRET_KEY, algorithms=["HS256"])  # whitelist only

Storing JWTs in localStorage

localStorage is accessible to any JavaScript on the page, making it vulnerable to XSS attacks. Use httpOnly cookies for web apps, or keep tokens in memory for SPAs.

Long-lived access tokens without refresh tokens

If an access token is compromised, you want it to expire quickly. Use short-lived access tokens (15–30 minutes) and longer-lived refresh tokens (7–30 days).

Not validating the `exp` claim

The python-jose library validates expiry automatically when decoding, but make sure you're not using options={"verify_exp": False} in production.

Putting sensitive data in the payload

The payload is Base64-encoded, not encrypted. Decode any JWT at jwt.io to see this in action. Only store non-sensitive identifiers (user ID, role).

Token Revocation: The Hard Problem

JWTs are stateless by design - there's no built-in revocation mechanism. If a token is stolen, it remains valid until it expires. Solutions:

Short expiry - 15-minute access tokens minimize the damage window
Refresh token rotation - issue a new refresh token on every refresh, invalidate the old one
Denylist - maintain a set of revoked token IDs (the jti claim) in Redis. Defeats some of the stateless benefit but gives you real revocation.

import redis
import uuid

r = redis.Redis()

def create_access_token(data: dict) -> str:
    to_encode = data.copy()
    to_encode.update({
        "jti": str(uuid.uuid4()),  # unique token ID
        "exp": datetime.now(timezone.utc) + timedelta(minutes=15),
    })
    return jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)

def is_token_revoked(jti: str) -> bool:
    return r.exists(f"revoked:{jti}")

def revoke_token(jti: str, ttl_seconds: int):
    r.setex(f"revoked:{jti}", ttl_seconds, "1")

Summary

JWT authentication is powerful when implemented correctly. The key things to remember:

Never store sensitive data in the payload
Use environment variables for secret keys
Keep access tokens short-lived, pair with refresh tokens
Whitelist algorithms when decoding
Understand the revocation tradeoff and design accordingly

The implementation above gives you a solid production foundation. From here, you can add email verification, OAuth2 social login, or 2FA on top of the same JWT infrastructure.

Building Production-Ready APIs with FastAPI

MEROLINE LIZLENT — Wed, 13 May 2026 07:48:29 +0000

If you are still using Flask or Django REST Framework to develop REST APIs but have yet to discover FastAPI, you are missing out on some real performance and developer experience. For all the right reasons, FastAPI is one of the most starred Python projects on GitHub and for a reason, it's more than just that.
Let's get very deep into how it works and let's make something real on the way.

What Is FastAPI?
FastAPI is a new, high-performance Python-based web framework designed to create APIs. It is built on top of Starlette (for web parts) and Pydantic (for data validation) and natively supports Python's async/await syntax.

Key selling points:
Benchmarks: On par with NodeJS and Go
Swagger UI and ReDoc: Automatic docs out of the box.
Type safety: Type annotations for validation and editor assistance in Python:
Async-first: First-class support for async request handlers.

Getting Started

pip install fastapi uvicorn[standard]

Your simplest possible app:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"message": "Hello, FastAPI!"}

Run it:

uvicorn main:app --reload

Visit http://127.0.0.1:8000/docs — you already have interactive Swagger docs. No extra config needed.

The Power of Pydantic Models
That's where FastAPI can help. Your request/response schemas are defined in Pydantic models and FastAPI is responsible for validation, serialization, and documentation.

from fastapi import FastAPI
from pydantic import BaseModel, EmailStr
from typing import Optional

app = FastAPI()

class UserCreate(BaseModel):
    name: str
    email: EmailStr
    age: Optional[int] = None

class UserResponse(BaseModel):
    id: int
    name: str
    email: str

@app.post("/users", response_model=UserResponse, status_code=201)
def create_user(user: UserCreate):
    # Simulate saving to DB
    return UserResponse(id=1, name=user.name, email=user.email)

FastAPI returns detailed responses for a malformed email or missing name without any extra code.

Path Parameters, Query Parameters, and Dependency Injection

from fastapi import FastAPI, Query, Depends, HTTPException

app = FastAPI()

# Path parameter
@app.get("/items/{item_id}")
def get_item(item_id: int):
    if item_id > 100:
        raise HTTPException(status_code=404, detail="Item not found")
    return {"item_id": item_id}

# Query parameters with validation
@app.get("/search")
def search_items(
    q: str = Query(..., min_length=3, max_length=50),
    skip: int = Query(0, ge=0),
    limit: int = Query(10, le=100),
):
    return {"query": q, "skip": skip, "limit": limit}

ge=0 (greater than or equal to) and le=100 (less than or equal to)- FastAPI validates these automatically.

Dependency Injection
FastAPI has a clean, built-in dependency injection system. It's great for things like database sessions, authentication, and shared logic.

from fastapi import FastAPI, Depends
from sqlalchemy.orm import Session
from database import SessionLocal  # your SQLAlchemy setup

app = FastAPI()

def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

@app.get("/users/{user_id}")
def read_user(user_id: int, db: Session = Depends(get_db)):
    user = db.query(User).filter(User.id == user_id).first()
    if not user:
        raise HTTPException(status_code=404, detail="User not found")
    return user

The get_db function is a dependency, FastAPI calls it before your route handler and cleans up after.

Background Tasks
Do you need to send an email or log something after returning a response? FastAPI's BackgroundTasks is perfect:

from fastapi import FastAPI, BackgroundTasks

app = FastAPI()

def send_welcome_email(email: str):
    # Your email logic here
    print(f"Sending welcome email to {email}")

@app.post("/register")
def register(email: str, background_tasks: BackgroundTasks):
    background_tasks.add_task(send_welcome_email, email)
    return {"message": "Registered successfully"}

The response is returned immediately the email is sent in the background.

Middleware
Add custom middleware for things like logging, CORS, or timing:

from fastapi import FastAPI, Request
from fastapi.middleware.cors import CORSMiddleware
import time

app = FastAPI()

# CORS
app.add_middleware(
    CORSMiddleware,
    allow_origins=["https://yourfrontend.com"],
    allow_methods=["*"],
    allow_headers=["*"],
)

# Custom timing middleware
@app.middleware("http")
async def add_process_time_header(request: Request, call_next):
    start = time.time()
    response = await call_next(request)
    duration = time.time() - start
    response.headers["X-Process-Time"] = str(duration)
    return response

Routers: Structuring Larger Applications
Don't put everything in main.py. Use APIRouter to split your app:

# routers/users.py
from fastapi import APIRouter

router = APIRouter(prefix="/users", tags=["users"])

@router.get("/")
def list_users():
    return [{"id": 1, "name": "Alice"}]

@router.get("/{user_id}")
def get_user(user_id: int):
    return {"id": user_id, "name": "Alice"}

# main.py
from fastapi import FastAPI
from routers import users, products, auth

app = FastAPI()
app.include_router(users.router)
app.include_router(products.router)
app.include_router(auth.router)

Testing FastAPI Apps

FastAPI integrates nicely with pytest via TestClient:

from fastapi.testclient import TestClient
from main import app

client = TestClient(app)

def test_create_user():
    response = client.post("/users", json={"name": "Bob", "email": "bob@example.com"})
    assert response.status_code == 201
    assert response.json()["name"] == "Bob"

Summary

There is a sweet spot to FastAPI: it's fast enough for production, ergonomic enough to get a prototype done fast, and typed enough to keep large bases maintainable. Saving hours of documentation work per project alone with the auto-generated docs.
As of today, unless you have a strong reason to do otherwise, FastAPI should be your top choice if you are building a new Python API project.

Exploratory Data Analysis (EDA) Workflow

MEROLINE LIZLENT — Mon, 20 Apr 2026 14:06:41 +0000

Introduction

Exploratory Data Analysis (EDA) is the crucial first step in any data project. It involves summarizing, visualizing, and understanding your dataset to uncover patterns, detect anomalies, and generate insights before modeling.

Why EDA Matters

Data is messier than ever (streaming sources, mixed types, missing values from APIs).
Models (including LLMs) are sensitive to data quality; bad EDA leads to garbage-in-garbage-out.
It's iterative and creative: ask questions, visualize, transform, repeat.

Core EDA Workflow

A solid, reusable EDA workflow typically follows these phases. It's not strictly linear you'll loop back often.

Understand the Business/Problem Context

What question are you trying to answer? (e.g., "Why is churn increasing?" or "What drives sales?")

Know the domain, key metrics, and stakeholders. This guides what to look for and prevents aimless exploration.
Load and Inspect the Data

Import your dataset and get a quick overview.
- Shape, data types, first/last rows, summary statistics.
- Check for duplicates, unexpected values, memory usage.
Data Cleaning & Quality Checks

Handle issues that would break downstream analysis:
- Missing values (percentage per column, patterns in missingness).
- Outliers and anomalies.
- Inconsistent formatting (dates, strings, categories).
- Incorrect data types (e.g., numeric stored as object).
Univariate Analysis (Understand individual variables)
- Numerical: histograms, box plots, summary stats (mean, median, std, skewness, kurtosis).
- Categorical: value counts, bar plots, frequency tables. Goal: Understand distributions and spot weirdness.
Bivariate & Multivariate Analysis Relationships between variables
- Numerical vs Numerical: scatter plots, correlation matrices/heatmaps.
- Numerical vs Categorical: box plots, violin plots, groupby aggregations.
- Categorical vs Categorical: stacked bars, crosstabs, chi-square if needed. Look for correlations, interactions, and potential confounders.
Feature Engineering & Transformations (during EDA)

Create new features (ratios, bins, groupings, time-based).

Apply log/power transforms for skewed data.

Test assumptions (normality, linearity).
Advanced Checks & Hypothesis Generation
- Segment analysis (group by key categories).
- Time-series specific (trends, seasonality if applicable).
- Dimensionality reduction (PCA, t-SNE) for high-dim data. Document insights, questions, and next steps.
Document & Communicate Findings

Create a clean notebook/report with key plots and takeaways.

Use storytelling: "We noticed X correlates strongly with Y, but only in segment Z."

Tools & Libraries

Core Stack:
- pandas + numpy — loading, cleaning, stats.
- matplotlib + seaborn — beautiful, statistical visualizations.
- plotly or altair — interactive plots.
Automation Boosters:
- pandas-profiling / ydata-profiling — one-line HTML report.
- Sweetviz, AutoViz, D-Tale — quick overviews.
- PandasAI — ask natural language questions about your DataFrame.
Others: scipy/statsmodels for deeper stats, missingno for missing data visualization.

Example starter imports:

import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
import seaborn as sns

# Optional modern additions
import plotly.express as px
# from ydata_profiling import ProfileReport

Practical Code Examples (Titanic Dataset Style)

Assume you have a DataFrame df.

Step 2-3: Quick Inspection & Cleaning

print(df.shape)
print(df.info())
print(df.describe(include='all'))  # includes categorical

# Missing values
print(df.isnull().sum() / len(df) * 100)

# Quick profile (if using ydata-profiling)
# ProfileReport(df, title="EDA Report").to_file("report.html")

Univariate Visualization

# Numerical
sns.histplot(df['age'], kde=True)
plt.title('Age Distribution')
plt.show()

# Categorical
sns.countplot(data=df, x='sex')
plt.show()

Bivariate

# Correlation heatmap
numeric_df = df.select_dtypes(include=np.number)
sns.heatmap(numeric_df.corr(), annot=True, cmap='coolwarm')
plt.title('Correlation Matrix')
plt.show()

# Relationship
sns.boxplot(data=df, x='pclass', y='fare')
plt.show()

Handling Issues

# Impute example (mean/median/mode or advanced)
df['age'] = df['age'].fillna(df['age'].median())

# Outlier detection (simple IQR)
Q1 = df['fare'].quantile(0.25)
Q3 = df['fare'].quantile(0.75)
IQR = Q3 - Q1
df = df[~((df['fare'] < (Q1 - 1.5*IQR)) | (df['fare'] > (Q3 + 1.5*IQR)))]

Mastering Regular Expressions in Go

MEROLINE LIZLENT — Mon, 20 Apr 2026 12:05:28 +0000

Go has an inbuilt regexp package which supports regular expression by the RE2 engine. This is because of this single and self-sufficient design choice, Go regexps are safe, predictable and production-ready.
RE2 is guaranteed O(n) time with respect to input length, avoiding disastrous backtracking and ReDoS vulnerabilities - even with untrusted user input.

1. Compile vs MustCompile
Before matching, a pattern must be compiled into a *regexp.Regexp. Two functions handle this:

// Compile → returns an error. Use for dynamic / user-supplied patterns.
re, err := regexp.Compile(`\d{3}-\d{4}`)
if err != nil {
    log.Fatal("invalid pattern:", err)
}

// MustCompile → panics on invalid pattern. Use for known-good package-level vars.
var phoneRe = regexp.MustCompile(`\d{3}-\d{4}`)

// Invalid pattern example
_, badErr := regexp.Compile(`[invalid`)
// error parsing regexp: missing closing ]: `[invalid`

2. Basic Matching
Three levels of match output — boolean, first match, all matches:

var digitRe = regexp.MustCompile(`\d+`)

text := "Order #4821 placed on 2024-06-15, total: $99.99"

fmt.Println(digitRe.MatchString(text))      // true
fmt.Println(digitRe.FindString(text))       // "4821"
fmt.Println(digitRe.FindAllString(text, -1)) // [4821 2024 06 15 99 99]
fmt.Println(digitRe.FindAllString(text, 2))  // [4821 2024]  (first 2)

3. Positional (Index) Matching
Index methods return byte offsets instead of strings — useful when you need to reconstruct or replace around the match.

loc := digitRe.FindStringIndex(text)
// loc = [7, 11]  →  text[7:11] = "4821"

allLocs := digitRe.FindAllStringIndex(text, -1)
// [[7 11] [22 26] [27 29] [30 32] [42 44] [45 47]]

Capture Groups (Numbered) Use FindStringSubmatch to get the full match plus all capture group contents. Index 0 is always the full match.

var ipRe = regexp.MustCompile(`(\\d{1,3})\\.(\\d{1,3})\\.(\\d{1,3})\\.(\\d{1,3})`)

m := ipRe.FindStringSubmatch("Server: 192.168.1.42")
// m[0] = "192.168.1.42"   (full match)
// m[1] = "192"             (group 1)
// m[2] = "168"             (group 2)
// m[3] = "1"               (group 3)
// m[4] = "42"              (group 4)

// FindAllStringSubmatch — all matches with their groups
allMatches := ipRe.FindAllStringSubmatch(input, -1)

5. Named Capture Groups
Syntax: _(?P...) _ makes code far more readable and survives pattern refactoring.

var dateRe = regexp.MustCompile(
    `(?P<year>\\d{4})-(?P<month>\\d{2})-(?P<day>\\d{2})`)

func ParseDate(s string) map[string]string {
    match := dateRe.FindStringSubmatch(s)
    if match == nil { return nil }

    result := make(map[string]string)
    for i, name := range dateRe.SubexpNames() {
        if name != "" { result[name] = match[i] }
    }
    return result
}

// ParseDate("2024-11-28") → map[year:2024 month:11 day:28]

//  direct index lookup by name
yearIdx := dateRe.SubexpIndex("year")  // 1

6. Replace Methods

// 1. ReplaceAllString — static, supports $N back-references
wsRe   := regexp.MustCompile(`\\s+`)
wsRe.ReplaceAllString("foo   bar  baz", " ")  // "foo bar baz"

swapRe := regexp.MustCompile(`(\\w+)=(\\w+)`)
swapRe.ReplaceAllString("a=1 b=2", "$2=$1")  // "1=a 2=b"

// 2. ReplaceAllStringFunc — dynamic via a function
digitRe.ReplaceAllStringFunc("item1 qty5", func(s string) string {
    n, _ := strconv.Atoi(s)
    return strconv.Itoa(n * 2)
})  // "item2 qty10"

// 3. ReplaceAllLiteralString — $ signs are NOT interpreted
litRe  := regexp.MustCompile(`foo`)
litRe.ReplaceAllLiteralString("foobar", "$1")  // "$1bar"

7. Split

sepRe := regexp.MustCompile(`[,;\\s]+`)

sepRe.Split("one,two; three  four", -1)
// ["one" "two" "three" "four"]

sepRe.Split("a,b,c,d", 3)  // ["a" "b" "c,d"]  (n=3 → at most 3 pieces)

8. Longest match

re.Longest() switches the engine to leftmost-longest (POSIX) semantics before the first call.

greedyRe := regexp.MustCompile(`a+`)
greedyRe.Longest()
greedyRe.FindString("aaa")  // "aaa"  (not just "a")

9. LiteralPrefix
LiteralPrefix() returns the fixed-string prefix before the first metacharacter. The engine uses this to fast-skip non-matching positions.

urlRe              := regexp.MustCompile(`^https://`)
prefix, complete := urlRe.LiteralPrefix()
// prefix = "https://"   complete = true

partialRe          := regexp.MustCompile(`^https?://`)
p2, c2          := partialRe.LiteralPrefix()
// p2 = "http"   c2 = false  (the ? breaks the literal)

10. Real-World: Email pattern checker

package main

import (
    "fmt"
    "regexp"
)

func main() {
    email := "test@example.com"

    // Simple email regex pattern
    pattern := `^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$`

    re := regexp.MustCompile(pattern)

    if re.MatchString(email) {
        fmt.Println("Valid email")
    } else {
        fmt.Println("Invalid email")
    }
}

When Should You Use RegExp?
Use it when:

Validating input (email, phone, etc.)
Parsing logs
Extracting structured data

Further Reading
Official docs: https://pkg.go.dev/regexp
RE2 syntax ref: https://pkg.go.dev/regexp/syntax
Run all examples: go run regexp_complete.go

DEV Community: MEROLINE LIZLENT

Bitcoin Keys and Addresses

From private key to public key

From public key to address

Segwit addresses: same idea, new encoding

A quick word on wallets

Vanity addresses, briefly

Wrapping up

Go: The Language That Just Works

Go by the numbers

What makes Go genuinely different

1. Concurrency as a first-class citizen

2. Blazing fast compilation

3. Static typing with type inference

4. Garbage collected with low latency

5. Batteries-included standard library

6. Single static binary output

7. Enforced formatting

8. Explicit error handling

Where Go dominates today

Go vs. the competition

Go vs. Python

Go vs. Rust

Go vs. Java / Node.js

Why Go is accelerating

Who should learn Go?

Where Go still falls short

Getting started

The bottom line

GitPython

Installation

Opening a Repository

Repository Basics

Cloning a Repository

Staging and Committing

Commit with Custom Author

Branches

Working with Remotes

Reading Commit History

Filter by Author, Path, or Date

Diffs: What Changed?

Tags

Reading File Contents from Git

Submodules

Real-World Patterns

Auto-Commit Changed Files

Generate a Changelog

Find Who Last Modified a Line (git blame)

Check if Branch Is Behind Remote

Using the Raw Git Interface

Summarizing

Pydantic v2: The Data Validation Library That Makes Python Feel Type-Safe

What Is Pydantic?

The Basics: BaseModel

Validation

Structured, machine-readable errors with field location, error type, and the offending input.

Field: Fine-Grained Validation

Custom Validators

Field Validators

Model Validators (Cross-Field Validation)

Types That Do the Heavy Lifting

Nested Models and Composition

Generics: Reusable Response Wrappers

Serialization: model_dump and model_dump_json

Aliases: Bridging Different Naming Conventions

Model Config: Customizing Behavior

Pydantic Settings: Managing Configuration

Computed Fields

Discriminated Unions: Polymorphic Models

Performance: Pydantic v2 Is Fast

Common Pitfalls

Mutable defaults

Modifying a model directly

Summary

JWT Authentication

What Is a JWT?

Header

Payload (Claims)

Signature

How JWT Authentication Works

`auth.py` — Core JWT Logic

`models.py`

`database.py` (Mock DB)

`main.py` — The Full Application

Using the `none` algorithm

Not validating the `exp` claim