The Best Prompt for Writing Python Code

Why this prompt works

How to use it

1. Write the task as behavior ("merge these files and drop duplicates"), then put every concrete detail you know about formats, column names and return types under inputs and outputs.
2. Set the Python version to the interpreter that will actually run the code, not the newest one. Check with python --version on the target machine.
3. Be strict about dependencies. If the script has to run somewhere you cannot install packages, write "Standard library only".
4. Read the restated behaviors and the assumptions before the code. If either is wrong, correct it in one reply and ask for the affected functions only.
5. Run the code against a small real sample, including one deliberately bad input, and paste any traceback back into the same conversation.
6. Use the edge-case table as a starting list for tests, then run a linter and type checker before committing the file.

AI model compatibility

“Expected to work” means the prompt uses plain, model-independent structure and has been reviewed for that — not that it has been run on that model. A model is marked Tested only when a test record is published below.

Worked example

Scenario: An operations analyst wants to replace a weekly copy-and-paste routine that combines order exports from several stores.

# Role
You are a senior Python engineer writing code that a colleague will maintain without you. Correct and readable beats clever.

# Spec
- What to build: Merge every CSV file in a folder into a single CSV, removing rows that repeat an order_id that has already been seen
- Inputs and outputs: Input: a folder path; each CSV has the columns order_id, order_date (YYYY-MM-DD), store, total. Output: one CSV at a path given by an --output argument, sorted by order_date, and a summary line on stdout with rows read, rows written and duplicates dropped
- Form: Command-line script
- Python version: 3.10
- Dependencies allowed: Standard library only
- Known edge cases and failure conditions: Some exports start with a UTF-8 BOM, a file may have the columns in a different order, and the folder may contain no CSV files at all

# Before you write code
1. Restate the spec as three to six testable behaviors ("given X, returns or writes Y").
2. List anything ambiguous. If an ambiguity would change the public interface or the data produced, stop and ask me. For anything smaller, choose the conservative reading and label it ASSUMPTION.

# Code requirements
- Follow PEP 8. Add type hints to every public function and a docstring that states arguments, return value and exceptions raised.
- Keep logic separate from I/O (files, network, command-line arguments, printing) so the logic can be imported and tested on its own.
- For a command-line script: argparse, a main() that returns an exit code, and an if __name__ == "__main__" guard. Errors go to stderr with a non-zero exit code.
- Validate input where it enters the program. Raise specific exceptions with messages that name the offending value. No bare except, no silently swallowed errors.
- Use only syntax and standard-library features that exist in the stated Python version, and import nothing outside the allowed dependencies. If you are not sure a function or parameter exists, say so instead of guessing.
- Write every function in full: no placeholder bodies, no TODO comments, no "rest of the implementation here".
- Build what the spec asks for and nothing more. Suggest extras in a closing note, not in the code.

# Output format
1. Assumptions - a short list, or "None".
2. Code - one fenced code block per file, with the filename on the line above it.
3. How to run - the exact command, plus one sample invocation and the shape of its output.
4. Edge cases - a table with columns: case, how the code handles it.
5. Not verified - anything you could not confirm without executing the code.

What a good response should contain

• A short list of behaviors, such as which copy of a duplicated order_id is kept, stated before the code
• An assumption or a question about files whose headers do not match the expected columns
• One file using csv and argparse from the standard library, with merging logic in a function that takes rows and a separate main() handling paths and exit codes
• A run command with the folder and --output arguments and a description of the summary line
• An edge-case table covering the BOM, reordered columns and the empty folder, and a note that the script has not been executed

This is an illustrative scenario showing how to fill in the prompt and what to look for. It is not a recorded model output. Recorded outputs will be published here once this prompt has a test record.

Testing and editorial review

No test record has been published for this prompt yet. When it is tested, this section will show the model and version, the date, the inputs, the actual output and notes against our seven-point rubric. We do not publish numerical scores.

Limitations and things to check

• Unless the tool you use can execute code, the model has not run the script. Treat it as unreviewed code until you have run it on real data.
• Library functions and parameters can be misremembered, especially for less common packages. Check unfamiliar calls against the package documentation.
• The prompt produces a first implementation, not a test suite. Pair it with the unit test prompt before relying on the code.
• Security-sensitive work such as handling credentials, parsing untrusted input or running shell commands needs review by someone qualified, whatever the output looks like.
• Performance is not addressed unless you state data sizes or time limits in the spec.

Alternative prompts

Related resources

All Coding prompts →

Frequently asked questions

Sources and references

1. PEP 8 – Style Guide for Python Code — Python Software Foundation
2. Prompt engineering overview — Anthropic
3. Prompt engineering guide — OpenAI

Was this prompt useful?