Help me implement this Python task in an existing codebase. Task: [PYTHON TASK] Project context: [PROJECT CONTEXT] Relevant existing code or interfaces: [EXISTING CODE] Python version and allowed dependencies: [ENVIRONMENT] Expected behavior and examples: [EXPECTED BEHAVIOR] First, inspect the constraints in my inputs and state any assumptions that materially affect the implementation. Ask up to 3 clarifying questions only if a required input is missing; otherwise proceed. Produce:
1. A short implementation plan naming the functions, modules, and data flow you will change. 2. Complete, runnable Python code or a unified patch, preserving the project’s existing style, typing approach, and error-handling conventions. 3. Focused tests using the project’s test framework. Include a normal case, boundary case, malformed or missing input case, and any regression case implied by the task. 4. A concise explanation of complexity, exceptions raised or handled, and how to run the code and tests. Engineering requirements: - Do not invent APIs, package behavior, files, schemas, or configuration values. Mark unknown integration details as TODOs with the exact question needed to resolve them. - Prefer standard-library tools unless the allowed dependencies justify another package. - Validate external input at the boundary; distinguish expected validation errors from programmer errors. - Avoid broad except clauses, mutable default arguments, hidden global state, and silent data loss. - Preserve deterministic behavior where ordering matters, and close files, connections, or async resources correctly. Before answering, self-check that every imported name and called method is supported by the supplied context or standard Python, and that the tests cover each stated acceptance criterion. Flag any claim or assumption not supported by my notes.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PYTHON TASK] | Describe the feature, bug fix, script, or function you need built. | Add CSV import validation for a customer upload endpoint and return row-level errors. |
| [PROJECT CONTEXT] | State what the application does and where this work fits in it. | FastAPI service that imports customer records into PostgreSQL; imports run synchronously for files under 5 MB. |
| [EXISTING CODE] | Paste relevant functions, models, tests, interfaces, or file paths. | app/imports/customers.py has import_customers(file); CustomerCreate requires email, full_name, and region; tests use pytest. |
| [ENVIRONMENT] | Give the Python version, framework, test runner, and permitted dependencies. | Python 3.12, FastAPI, SQLAlchemy 2.0, pytest; use only installed dependencies and the standard library. |
| [EXPECTED BEHAVIOR] | List inputs, outputs, acceptance criteria, and a few representative examples. | Accept UTF-8 CSV with email, full_name, region. Reject duplicate emails in file, invalid emails, blank names, unknown regions; import valid rows only if no errors. |
How to use
- Paste the task and enough surrounding code for Copilot to see the real interfaces.
- Specify Python version, test runner, and dependency limits before requesting a patch.
- Run the proposed tests and compare exception behavior with the project’s existing conventions.
- Follow up with: “Revise this patch to match this failing test output: [TEST OUTPUT]. Do not change unrelated behavior.”
Variations
Debug a traceback
Use this when code fails and you need a targeted diagnosis before a rewrite.
Diagnose and fix this Python failure. Traceback: [TRACEBACK] Failing code: [CODE] Expected result: [EXPECTED RESULT] Runtime context: [ENVIRONMENT] Explain the root cause in plain language, then provide the smallest safe patch and a regression test. Consider null values, type mismatches, ordering, resource cleanup, and version-specific behavior. Do not guess missing package or API behavior. Before answering, verify that the patch addresses the traceback line and that the test would fail before the patch.
Write a utility
Use this when you need a small reusable function with a defined contract.
Write a production-ready Python utility. Function purpose: [FUNCTION PURPOSE] Inputs and output: [CONTRACT] Examples: [EXAMPLES] Constraints: [CONSTRAINTS] Return a typed function, docstring, and pytest tests. Define behavior for empty input, invalid input, and boundary values; state exceptions explicitly. Use the standard library unless [CONSTRAINTS] permits otherwise. Include time and space complexity. Self-check that examples match the implementation and that no input is mutated unless the contract says it may be.
Review a pull request
Use this when you want an engineering review focused on correctness risks.
Review this Python change as a careful maintainer. Change or diff: [DIFF] Relevant contract: [REQUIREMENTS] Runtime details: [ENVIRONMENT] Existing tests: [TESTS] List findings by severity: blocking correctness issues first, then reliability, security, performance, and maintainability. Cite the exact code path and explain a realistic failure case for each finding. Suggest minimal fixes and missing tests. Do not praise style or invent issues. Self-check that each finding follows from the supplied code and requirements.
Tips
- Give Copilot the actual function signature and one existing test; this prevents it from creating a parallel interface that the application never calls.
- For parsing or imports, state whether partial success is allowed, because all-or-nothing and row-level error handling lead to very different code.
- Ask for a regression test tied to the bug’s triggering input, not just a happy-path test that exercises the new function.
- Treat generated migrations, authentication code, and deletion logic as drafts until you verify them against the project’s models and deployment rules.
FAQ
Can Copilot write Python tests too?
Yes. Give it the test framework and existing test patterns, then require cases for invalid inputs and the reported failure path.
How do I stop it from using unavailable libraries?
Name the Python version and allowed dependencies in the prompt. Ask it to mark any missing integration detail instead of guessing.
Should I paste the entire repository?
Usually no. Paste the relevant module, interfaces, configuration constraints, and nearby tests so the answer stays focused.