Best Tabnine Prompts for Python Script Debugging: Beginner-Friendly Guide

You wrote a Python script, it crashed or printed the wrong thing, and the traceback might as well be in another language. This guide gives you Tabnine prompts for Python script debugging that a beginner can paste into the chat panel of their editor and get useful, checkable answers. Every prompt below is already filled in with a realistic situation, with only a few [BRACKETED] fields for you to swap.

How Tabnine fits debugging (and where it does not)

Tabnine is an AI coding assistant that works inside your IDE: inline completions plus a chat you can ask about the file or selection you have open. That makes it well suited to explaining errors, proposing small fixes and writing tests next to your code. Its limits are the same as any assistant: it cannot run your script on your data, it can guess wrong when it cannot see the file that actually fails, and it may produce a confident fix that is subtly incorrect. Features and context options differ by plan and version, so check the tool's current features, limits and privacy settings (especially if the code is your employer's) before pasting anything sensitive.

Treat every answer as a suggestion from a fast junior colleague: useful, then verified by you.

The debugging prompt formula

Good debugging prompts have six parts. Missing parts are the main reason beginners get vague answers.

1. Environment: Python version, OS, key libraries and versions.
2. Goal: what the code should do in one sentence.
3. Evidence: the full traceback or the wrong output, plus the expected output.
4. Scope: which function or lines to look at (select them in the editor first).
5. Constraints: minimal change, no new dependencies, keep function signatures.
6. Output format: explain the cause first, then a diff-style fix, then how to confirm it.

Scenario 1: Priya's CSV report script crashes

Priya works in a small logistics office in Pune. Her script merges a weekly shipments.csv (about 12,000 rows) with a carriers.csv lookup and writes a summary. It ran fine last week and now fails.

Prompt 1: Explain a traceback in plain English

I'm a beginner. Python 3.11, pandas 2.x, Windows 11. My script weekly_report.py merges shipments.csv with carriers.csv and prints totals per carrier. It worked last week and fails today with this traceback:

Traceback (most recent call last):
  File "weekly_report.py", line 27, in <module>
    merged = shipments.merge(carriers, on="carrier_id")
  File ".../pandas/core/reshape/merge.py", line 1060, in _maybe_add_join_keys
ValueError: You are trying to merge on object and int64 columns.

Explain in plain English what this error means, which of my two files is likely causing it, and why it might appear only this week. Then give 3 checks I can run in order (print dtypes, find non-numeric values, etc.) with the exact code for each. Do not change my merge logic yet.

Why it works: it supplies the full traceback and the "worked last week" clue, and it forbids a premature rewrite so you learn the cause first. What to expect / check: an explanation that one carrier_id column holds text (for example a stray "N/A" or an ID with a leading zero). Failure mode: the assistant assumes a cause without seeing your data, so run the checks rather than trusting the guess. Iterate: "Check 2 printed these 4 non-numeric values: [PASTE]. Which are data errors versus valid IDs, and what is the safest way to clean them without dropping rows silently?"

Prompt 2: Fix with the smallest possible change

Context: the dtype check showed carriers.csv has carrier_id values like "007" (text with leading zeros) while shipments.csv stores 7 as an integer. Python 3.11, pandas 2.x.

Task: propose the smallest change to lines 20-27 of weekly_report.py so both columns are compared as the same type. Constraints: keep variable names, no new libraries, do not drop rows, and add one assertion after the merge that fails loudly if any shipment ends up with no carrier match. Output: a before/after diff and two sentences on why leading zeros matter here.

Why it works: the constraints stop a rewrite, and the assertion turns a silent data problem into a visible one. What to expect / check: a .astype(str).str.zfill(3) style fix or pd.to_numeric. Check the row count before and after the merge yourself. Iterate: "Now rewrite the assertion so it prints the first 5 unmatched shipment IDs instead of only raising."

Prompt 3: Handle a missing file or bad input without hiding errors

Python 3.11. weekly_report.py opens "shipments.csv" from the current folder. On my colleague's machine it fails with FileNotFoundError, and on mine it fails with UnicodeDecodeError on the same file after she re-saved it from Excel. Explain both errors in two sentences each. Then show how to open the file with an explicit path relative to the script (pathlib), an explicit encoding, and a try/except that prints a clear message naming the file and the likely fix. Do NOT use a bare except and do not swallow errors silently.

Why it works: two symptoms plus a ban on bare except steers toward specific, honest error handling. What to expect / check: Path(__file__).parent, encoding="utf-8-sig" or similar. Test by renaming the file on purpose. Iterate: "Add a command-line argument for the file path using argparse, defaulting to shipments.csv beside the script."

Scenario 2: Wrong output with no error

Daniel runs a small online shop and wrote a script that applies tiered discounts. It never crashes but a 100-item order gets the wrong price.

Prompt 4: Trace the logic with a worked example

Python 3.12, no libraries. Select the function apply_discount below. Rules: 1-9 items 0% off, 10-49 items 5% off, 50+ items 10% off. Unit price 4.00. Expected: 100 items = 360.00. My function returns 380.00.

[PASTE FUNCTION]

Walk through the function line by line with quantity=100 and show the value of each variable at each step in a small table. Identify the exact line where behaviour diverges from the rules. Then list the boundary values I should test (9, 10, 49, 50, 0, negative) and what each should return.

Why it works: a concrete input and expected output let the model simulate execution, which is more reliable than "why is this wrong?" What to expect / check: usually an elif ordering bug. Verify by running the boundary list yourself. Iterate: "Write the fix, then write a pytest parametrized test covering every boundary you listed."

Prompt 5: Generate logging, not scattered prints

Python 3.12. The function below returns the wrong total only for orders that mix discounted and non-discounted items. Add temporary debugging output using the logging module at DEBUG level (not print), showing inputs, each intermediate total and the return value. Keep the logic untouched, mark each added line with # DEBUG so I can delete them later, and show me the command to run the script so the DEBUG lines appear.

[PASTE FUNCTION]

Why it works: it separates observation from change and makes cleanup easy. What to expect / check: logging calls with a basicConfig(level=logging.DEBUG) line. Confirm no # DEBUG line alters behaviour. Iterate: "Here is the log output: [PASTE]. Which step first disagrees with my expected value of [NUMBER]?"

Prompt 6: Mutable default and scope bugs

Python 3.11. This function sometimes returns items from a previous call. Review ONLY for state-leak bugs such as mutable default arguments, shared module-level lists, and variables modified in place. Quote the exact line for each suspect, explain with a 5-line reproduction I can paste into a REPL, and give the fix. If you find no such bug, say so rather than inventing one.

[PASTE FUNCTION]

Why it works: narrowing the search class and permitting "no bug found" reduces invented problems. What to expect / check: the classic def add(item, bucket=[]). Run the reproduction to confirm. Iterate: "Explain the same bug using a real-world analogy in three sentences so I remember it."

Prompt 7: Floating point and rounding surprises

Python 3.12. My invoice script shows totals like 359.99999999999994 and sometimes a one-cent mismatch against the accounting export. Currency is GBP, two decimals, VAT 20% applied per line then summed. Explain why this happens in plain English, then show how to use the decimal module for this calculation with ROUND_HALF_UP, keeping the function signature. Include a 4-case test with a value that exposes the old behaviour. Add a note on where per-line versus per-invoice rounding would change the total.

Why it works: domain rules (currency, rounding point) are what turn a generic answer into a correct one. What to expect / check: Decimal("...") built from strings, not floats. Compare against your accounting source, since rounding rules are business decisions. Iterate: "Show the same invoice calculated both ways so I can see the difference in pence."

Scenario 3: A script that has become slow

Prompt 8: Find the bottleneck before optimising

Python 3.11. My script processes 80,000 log lines and takes about 9 minutes. I suspect the nested loop in parse_logs(). Do not rewrite anything yet. First show how to profile with cProfile (exact command and how to read the top 10 lines of output). Then, from the code below, list the 3 most likely causes of slowness in order, each with the complexity (for example O(n^2)) and how I would confirm it.

[PASTE CODE]

Why it works: "measure first" prevents speculative rewrites. What to expect / check: suggestions like list membership tests inside loops. Confirm with the profiler output, not the model's opinion. Iterate: "The profile shows 70% of time in is_known_ip. Rewrite only that function using a set and keep behaviour identical."

Prompt 9: Safe refactor with tests first

Python 3.11, pytest. Before I change anything, write 6 pytest tests that lock in the CURRENT behaviour of parse_logs() on these sample lines [PASTE 4-6 LINES], including one malformed line and one empty line. Do not modify the function. Explain what each test protects against.

Why it works: characterisation tests let you refactor without breaking behaviour. What to expect / check: tests that pass on the unmodified code. If one fails, the assistant misread the function. Iterate: "Now suggest a faster version and show which tests, if any, fail."

Prompt 10: Security review of a script that takes input

Python 3.11. This script takes a filename and a search term from the command line and runs grep through subprocess with shell=True, then writes results to a path built from the filename. Review it for command injection, path traversal and unsafe file writes. For each issue: quote the line, show an input that would exploit it (harmless demo only), and give a safer replacement (argument list without shell, pathlib resolve and a check against an allowed folder). Tell me which issues are real and which are low risk for a script only I run.

[PASTE CODE]

Why it works: it asks for demonstrable issues and a risk judgement, not a vague "is this secure?". What to expect / check: shell=False with a list. Test the safer version with awkward filenames. Never rely on the assistant as your only security review for anything exposed to other users. Iterate: "Rewrite the main function with those fixes and add three tests for hostile inputs."

Worked example: from vague to useful

Prompt 1 (weak): "my script doesnt work fix it"

Typical result: a generic list of "check your indentation, make sure packages are installed", or a full rewrite of the file that changes behaviour you did not ask about. You cannot tell what was wrong.

Prompt 2 (improved):

Python 3.11 on macOS. fetch_prices.py should read tickers.txt (one symbol per line) and print the closing price from the API response. It prints "KeyError: 'close'" on the third ticker only. Here is the function and the raw JSON returned for ticker 3: [PASTE]. Explain why the key is missing for that ticker, then change the function to handle it by logging a warning and skipping, without altering how the other tickers behave.

Why it is better: it gives the environment, the symptom location (third ticker only), the raw data and a bounded fix. The answer will point to a response with a different shape and give a targeted guard.

End-to-end workflow: debug a broken script in six steps

1. Reproduce: run the script and copy the full traceback. Ask Prompt 1 to explain it.
2. Narrow: select the failing function and use Prompt 4 or 6 to find the divergence point.
3. Lock in behaviour: use Prompt 9 to write tests for current behaviour.
4. Fix minimally: use Prompt 2 style, with constraints.
5. Add a regression test for the exact bug:

Python 3.11, pytest. Write one regression test named test_[BUG_NAME] that fails on the old code and passes on the fixed code below. Include a one-line comment saying what bug it guards against.

[PASTE FIXED FUNCTION]

1. Review the diff yourself against the checklist below before committing.

Troubleshooting

| Problem | Likely cause | Fix | |—|—|—| | Answer is generic | No traceback, version or code included | Paste the full error, Python version and the selected function | | Fix introduces a new bug | No constraints on scope | Add "smallest change, keep signatures" and ask for tests | | References functions that do not exist | The model cannot see other files | Paste the helper or say "assume nothing beyond what I pasted" | | Suggests a library you do not use | Open-ended request | Add "standard library only" | | Confident but wrong explanation | Guess without data | Ask for checks you can run, then paste results back |

Review checklist before you keep the fix

• Did you run the original failing case and see it pass?
• Did you run the boundary cases and a normal case?
• Is the change as small as you expected, with no unrelated edits?
• Does any code build SQL, shell commands or file paths from user input? Check for injection and path problems yourself.
• Did it add dependencies you do not want?
• Can you explain the fix in your own words? If not, ask for a simpler explanation before merging.

For more on testing generated code, see these unit test prompts for Bolt.new, and for careful handling of risky scripts see GitHub Copilot prompts for database migration scripts. If you want to automate the boring parts around your scripts, there is also a guide to AI prompts for workflow automation.

FAQ

Can Tabnine fix my Python bug automatically?

It can suggest fixes in chat, but you decide whether to apply them. Always run your tests and the failing case afterwards.

Should I paste my whole project?

No. Paste the failing function, the traceback and any helper it calls. Less context that is relevant beats a large dump, and it keeps private code private.

Is it safe to use with company code?

Check your employer's policy and Tabnine's current privacy and deployment options for your plan before pasting proprietary code.

Why does the explanation sound right but the fix fails?

Models explain plausibly even when guessing. Ask for runnable checks, paste the results back, and iterate with real evidence.

What if I still do not understand the fix?

Ask: "Explain this fix to someone who has been learning Python for one month, with a three-line example." Understanding is part of debugging.

Conclusion

The best Tabnine prompts for Python script debugging share a pattern: real environment details, the full evidence, a narrow scope, a minimal-change constraint and a way to verify. Start with Prompt 1 on your next traceback, keep the tests, and review every diff yourself.