Python Advanced Python Projects

Start from the workload and the rules, then define components and the interfaces between them:

• Policy: the booking rules (no overlaps, opening hours, maximum length). Pure Python, no I/O.
• Storage: saving and loading bookings, behind an interface such as a Protocol with bookings_for(room) and add(booking).
• Delivery: an HTTP API (Flask or FastAPI) or command-line tool that translates requests into policy calls.

from typing import Protocol

class BookingStore(Protocol):
    def bookings_for(self, room: str) -> list[tuple[int, int]]: ...
    def add(self, room: str, start: int, end: int) -> None: ...

def can_book(store: BookingStore, room: str, start: int, end: int) -> bool:
    if not (8 <= start < end <= 22):
        return False
    return not any(overlaps((start, end), existing) for existing in store.bookings_for(room))

The policy can be tested with an in-memory store and run in production with a database store, unchanged. Choosing a framework doesn't create a design; a Flask app whose route functions contain SQL, rules and formatting is still one tangled function per endpoint. Write down each decision and its reason in a short architecture note in the repository.

Reliable software keeps its data correct and its failures understandable:

• Validation at the boundary: reject impossible requests with clear messages and correct status codes.
• Transactions: a booking check and insert must happen in one database transaction, or two simultaneous requests can both pass the check and double-book a room.
• Logging: record each booking, rejection and error with an ID, never personal data.
• Tests: unit tests for policy edge cases, integration tests against a real test database, and tests for failure paths, such as the database being unavailable.

import sqlite3
def book(conn, room, start, end):
    with conn:                                   # one transaction
        clash = conn.execute(
            "SELECT 1 FROM bookings WHERE room = ? AND start < ? AND ? < end",
            (room, end, start)).fetchone()
        if clash:
            return False
        conn.execute("INSERT INTO bookings VALUES (?, ?, ?)", (room, start, end))
        return True

A demonstration that shows only the happy path, one valid booking, says nothing about reliability. The tests for overlapping, adjacent, out-of-hours and concurrent requests are what demonstrate it.

Optimise only with evidence. Measure a representative workload first, find where time actually goes, then change the slow part and measure again:

import timeit
setup = "bookings = [(h, h + 1) for h in range(8, 22)] * 500"
print(timeit.timeit("any(s < 15 and 14 < e for s, e in bookings)", setup=setup, number=1000))

Use timeit for small snippets and cProfile (python -m cProfile -s cumtime app.py) for whole programs. Often the bottleneck is somewhere unexpected: one database query per booking, reading a file repeatedly, or an O(n²) loop over all bookings. The usual fixes are a database index on (room, start), a single query instead of many, or a better data structure.

An unmeasured "optimisation" often adds complexity, such as caching or concurrency, without any benefit, and can introduce bugs. Record before-and-after numbers in the commit message or architecture note so reviewers can see the improvement was real.

An advanced project is delivered as a package another maintainer can work with:

• README: purpose, architecture overview, set-up, configuration, running and testing.
• Configuration through environment variables, with an .env.example and no secrets in the repository.
• Dependencies declared in pyproject.toml with a lock file.
• Automated checks: tests, linting, formatting and type checking running in continuous integration.
• Documented limits: what the project doesn't handle yet, such as time zones or recurring bookings.

.github/workflows/ci.yml   pytest, ruff, mypy on every push
docs/architecture.md       components, decisions and trade-offs
.env.example               BOOKING_DB_URL=sqlite:///bookings.db

For a portfolio, describe what the project actually demonstrates: "a tested booking API with transactional conflict checks", not "a scalable enterprise platform". Honest, specific claims backed by code and tests are far more convincing to reviewers and employers.

Task: build a tested booking service, a reproducible data report or an evaluated model pipeline with documented architectural choices. Start the booking service with policy tests that pin down the rules:

def overlaps(a, b):
    return a[0] < b[1] and b[0] < a[1]

cases = [
    (((9, 11), (10, 12)), True),     # partial overlap
    (((9, 11), (11, 12)), False),    # adjacent half-open intervals
    (((9, 12), (10, 11)), True),     # one inside the other
    (((13, 14), (9, 11)), False),    # separate
]
for (a, b), expected in cases:
    assert overlaps(a, b) == expected and overlaps(b, a) == expected, (a, b)
print("overlap rules pass in both directions")

Then add storage behind an interface, a transactional database version, an HTTP layer and a README with an architecture section. For the worked check: do adjacent half-open booking intervals overlap? No. A booking ending at 11 and one starting at 11 share no time.

The documentation for timeit and the Python profilers explains measurement. Continue with the study roadmap, and revisit Flask, type checking and pytest as you build.