Verified against ChatGPT · 2026-07-14
Turn a plain-English function spec into fully type-hinted Python
A prompt that converts a rough description of what a function should do into PEP 484-typed Python with explicit edge-case handling and a docstring, instead of untyped happy-path code.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are writing a single Python function to a strict spec, not a rough sketch. Every parameter, return value, and raised exception must be typed and documented before you write the implementation. SPEC Given a list of order dicts (each with "amount" and "currency"), return the total in USD, converting non-USD amounts using a provided rate table. TARGET ENVIRONMENT Python 3.12+. Use only the standard library, plus these packages if genuinely needed: stdlib only, no third-party packages REQUIREMENTS 1. Full type hints on every parameter and the return type — no bare Any unless you name, in a comment, why nothing more specific is possible. 2. A docstring in Google or NumPy style: one-line summary, Args, Returns, Raises. 3. Explicit handling for: empty list input, an order missing the "amount" key, a currency not present in the rate table, a negative amount. Do not silently swallow an error — raise a specific exception type, never a bare except with no type named. 4. If the function has an obvious failure mode not covered by empty list input, an order missing the "amount" key, a currency not present in the rate table, a negative amount, name it and handle it anyway — don't wait to be told about every case. 5. No print statements for control flow or debugging — use the logging module if you need to observe behavior during development. OUTPUT FORMAT 1. The function, fully typed and documented. 2. A short note for each edge case in empty list input, an order missing the "amount" key, a currency not present in the rate table, a negative amount: one line on how it's handled and what it returns or raises. 3. One realistic call example showing the happy path, and one showing a handled failure.
Customize the highlighted detailsoptional — the prompt above already works
Why this works
Naming the edge cases explicitly in the prompt, rather than trusting the model to infer them, directly counters the well-documented happy-path bias of LLM-generated code — a model asked to just "write this function" will produce a version that works for the example in its head and silently mishandles everything else. Requiring the exception type and forbidding a bare except turns "handle errors" from a vague aspiration into something a reviewer can check by reading the except clauses. The instruction to name a failure mode not on the list, and handle it anyway, matters because the edge_cases variable can never be exhaustive — this is what stops the model from treating the given list as a ceiling rather than a floor. Finally, forcing full type hints before implementation, rather than as cleanup afterward, produces code that a strict mypy pass actually has a chance of accepting on the first try, instead of hints bolted on that quietly widen to Any wherever the model wasn't sure.
What you get back
def total_in_usd(orders: list[dict[str, str | float]], rate_table: dict[str, float]) -> float: """Sum order amounts converted to USD. Args: orders: Each dict must have "amount" (float) and "currency" (str). rate_table: Maps currency code to its USD conversion rate. Returns: Total value in USD, rounded to 2 decimal places. Raises: KeyError: If an order is missing "amount" or "currency". ValueError: If a currency isn't in rate_table, or amount is negative. """ total = 0.0 for order in orders: amount = float(order["amount"]) currency = str(order["currency"]) if amount < 0: raise ValueError(f"negative amount not allowed: {amount}") if currency == "USD": total += amount elif currency in rate_table: total += amount * rate_table[currency] else: raise ValueError(f"no conversion rate for currency: {currency}") return round(total, 2) Edge case notes: empty list returns 0.0 (loop just doesn't execute); missing "amount"/"currency" raises KeyError from the dict access itself; unknown currency raises ValueError naming the currency; negative amount raises ValueError before any arithmetic happens.
Verified against
ChatGPT GPT-5.1 · 2026-07-14
Claude Sonnet 4.6 · 2026-07-16
Changelog
- 2026-07-16 — Initial publish, verified against ChatGPT (GPT-5.1) and Claude (Sonnet 4.6).
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
