Python Code Scanner Guide: Inspect, Check, and Clean Up Source

Inspect Python without generative AI

Check the file, don’t solve the homework. The Python code inspector uses defined visibility checks, the Python compiler, and static name analysis. It does not ask a language model to interpret your assignment, generate answers, or write a solution.

You control every cleanup change: preview offered edits before applying them, keep the original when appropriate, and export only the copy you reviewed. The inspector does not automatically rename variables. Its checks do not prove program correctness or determine whether work was AI-generated.

This describes how the Python inspector works, not permission to use it in every course. Follow your instructor’s or institution’s rules for outside tools. The separate document scanner can use OCR, which can involve machine learning; the site-wide claim is no generative AI analysis, not that every component is AI-free.

1. Start a Python code inspection

Open Inspect Code, paste your source or load a UTF-8 .py file, and select Inspect code. Each source is limited to 1 MiB. Preserve your original file before making changes. Loaded files retain their BOM and line endings until you edit the textarea; textarea editing uses its normalized line endings.

The source scanner reports supported invisible Unicode, confusing punctuation, indentation patterns, mixed line endings, trailing whitespace, and selected confusing identifier spellings. These are observations for review. Ordinary non-ASCII names and legitimate text inside strings are not automatically mistakes.

2. Read visibility findings beside the code

Use Show line to locate a finding in the selected Original source or Cleaned copy view. Technical details expands the rule and context information. Longer sources and finding lists are paged; very long code lines show excerpts around the selected location.

A tab or trailing-space finding is not the same as a Python compiler error. Trailing whitespace is often cosmetic. Mixed tabs and spaces can affect indentation even when an editor makes the lines appear aligned. A finding without Review fix requires manual review; the inspector does not invent an indentation correction.

Reviewed Unicode and punctuation scope

The scanner reviews a small documented set of copy/paste hazards: selected zero-width and bidirectional controls, selected unusual spaces, and selected punctuation that resembles Python syntax. It shows the exact Unicode code point and name. This is not a claim to find every Unicode confusable character.

Identifier review is limited to selected mixed-script and look-alike evidence in executable code, not strings or comments. Names written in more than one language can be intentional. The scanner does not rename identifiers; compare the reported code points with the surrounding bindings before making your own edit.

Formatted and template strings are intentionally conservative. Unicode remains visible there, but identifier and punctuation advice inside replacement expressions is suppressed when lexical boundaries are uncertain. A review-only finding means the surrounding syntax or intent needs human judgment.

3. Run the syntax and undefined-name checks

Select Check syntax and names in the section below the visibility results. The optional check uses Python 3.14.2 in a browser worker. Its initial runtime download is about 13 MB from this application, plus a small local name-analyzer package. Later checks on the same page reuse the loaded runtime, so they usually finish in well under a second. The program you paste is never executed.

For a Python indentation error, invalid character in Python, or name is not defined question, start with the matching lane: visibility can reveal a hidden or confusing character; syntax reports the first compiler location; names can flag some unresolved names only after syntax is valid. The displayed location and excerpt guide your review, but they do not prove the intended fix or that the program works.

Original source and Cleaned copy each receive a syntax result. Python reports the first compiler error for that copy, plus its compiler warnings, such as comparing with is instead of ==, an invalid backslash escape like \d in an ordinary string, or a return inside a finally block. If syntax passes, the analyzer looks for unresolved names, local variables used before assignment, unused imports and variables, and a reviewed set of common mistakes, such as format strings that do not match their values or a dictionary key repeated with different values. These findings have their own source-location buttons; they do not appear in the visibility findings list. When the original and cleaned copy are identical, results appear once.

A misspelled variable such as usernmae can be valid Python syntax but still refer to no known binding. Imports and aliases count as bindings without checking whether a package is installed, compatible, or safe. Wildcard imports, dynamic namespaces, notebooks, and framework injection can supply names the scanner cannot resolve; treat those findings as uncertain.

Reading finding levels and tips

Every finding has a level. Error means Python cannot run the file. Likely bug means the line will probably fail or misbehave when it runs, such as an undefined name or a format string with the wrong number of values. Security marks code that could be risky if any input comes from someone else. Warning deserves a closer look. Tip is an optional cleanup, such as an unused import. Each level has its own label, shape, and border style, so the levels are not told apart by colour alone.

Each finding shows its line and column when Python provides one, what the compiler or analyzer reported, why it matters, and what to check or change. The advice describes what to investigate; it does not edit your code, and a finding can still be intentional in context.

Tips are shown by default. Turn off Show tips to hide them; errors, likely bugs, security signals, and warnings always stay visible. When three or more tips of the same kind appear, such as several unused imports, they are grouped into one card that lists each location.

Security signals: code that is risky with untrusted input

Findings labelled Security point to code that is fine when every value comes from you, but risky when any part can come from a user, a file, or the network. They cover eval() and exec() on values built at runtime, pickle, marshal and yaml.load() without a safe loader, shell commands built with + or f-strings, SQL built with f-strings, + or %, passwords and API keys written into the code, certificate checking turned off, MD5 or SHA-1 used for passwords, the random module used for tokens or passwords, debug mode on a web app, tempfile.mktemp(), and file permissions that let every user change a file.

Each signal fires only when the risky value can change while the program runs, so fixed text such as os.system("clear") or eval("1 + 2") stays quiet, and so do the usual safe patterns: query placeholders, subprocess argument lists, yaml.safe_load(), ast.literal_eval(), os.environ, and the secrets module. A secret-looking value is shown masked, such as hu••••2, so a screenshot of the results does not reveal it.

These are automated code-review signals, not a security audit. A signal is not proof of a vulnerability, and no signals does not mean the code is secure: the checker reads one file, never runs it, and cannot see where values really come from. Security signals always stay visible, even when tips are hidden.

Code-quality checks and the file outline

Warnings also cover list, dict or set default arguments that are shared between calls, except: with no exception type, errors ignored with except Exception: pass, code after return, raise, break or continue that can never run, methods without self, and lambdas in a loop that all see the loop variable's last value. Tips cover == None, == True or == False, names such as list or sum that replace a built-in, and files opened without with.

File outline lists the functions, classes, and imports in the file with a button that shows each line, plus the longest function, the function with the most decision points, and the deepest nesting. These measurements describe the code's shape to help you find where to look first; they are not a grade.

Checking code copied from a notebook

Jupyter and Colab commands such as %matplotlib inline, !pip install, or files = !ls work in notebooks but are not Python, so a .py file containing them fails the syntax check. When the first syntax error is on a line like that, the results explain it and offer Check again as notebook code.

In notebook mode, only lines that Python rejects and that start like a notebook command are skipped, one at a time, so ordinary syntax errors are still reported. A skipped command becomes pass, an assignment such as files = !ls keeps its name, and line numbers stay the same. The notebook helpers display and get_ipython are treated as defined. Notebook mode ends when the source changes.

Very large or deeply nested code

The checker runs inside your browser, which has much less room for deeply nested code than Python on a computer. Before compiling, it measures how deeply brackets and expressions are nested. Brackets nested 200 or more levels deep are reported with Python's own error, too many nested parentheses. Between about 180 and 199 levels, and for single expressions that chain about 1,800 or more operations, syntax is not checked and the result explains why and where.

Name and mistake checks are skipped for code nested more than about 320 levels deep, such as a very long chain of + or elif, and the syntax result is kept. If the browser checker still fails, it is restarted for the next step and the results that finished are kept. A check that runs past 60 seconds also keeps the steps that finished. Splitting a very long expression into smaller statements avoids these limits.

Static name-analysis policy

The analyzer reports only bounded static observations from Pyflakes: possibly unresolved names, wildcard-import uncertainty, unused imports and local variables, names listed in __all__ but never defined, and a reviewed set of mistakes that Pyflakes reports precisely. A use before a later local assignment may be reported as possibly unresolved rather than as proof of the intended scope. Python’s compiler separately reports syntax-state errors such as invalid indentation or a return outside a function. Neither result executes the source or proves runtime behavior.

A second definition is reported only when the first one is replaced before anything uses it; Pyflakes already allows conditional imports, try/except fallbacks, and @overload. Other rebinding is not reported, because it can be intentional in decorators, methods, type declarations, compatibility code, tests, and framework hooks. An unused import is a tip, not an error, because some imports are kept on purpose for their side effects or to re-export a name. It also does not diagnose package installation, imports across a project, attribute spelling, type correctness, or framework-provided globals.

Modern valid syntax—including match captures, comprehensions, exception aliases, global and nonlocal declarations, type parameters, decorators, annotations, and async constructs—is a clean control for this release. A partial snippet can still legitimately depend on surrounding program context.

Why does it say name checks were skipped?

Name inspection needs a valid syntax tree. For example, TabError: inconsistent use of tabs and spaces in indentation means Python rejected the source before name checking. Skipped with zero findings means not checked, not that every name is correct.

Fix the reported indentation in your editor, preserving the intended block structure, and inspect the corrected source again. Use spaces consistently for the affected blocks; do not blindly replace every tab in the file because tabs inside strings may be intentional. If cleanup decisions lock the input, save any copy or audit you need, then reset decisions or start a new inspection before replacing the source.

Correct the first syntax error, then recheck: Python may reveal another error afterward. Incomplete snippets can fail as standalone files even when they make sense inside a larger function or program.

4. Preview cleanup before applying a fix

Review fix opens the current and proposed text side by side. Labels make spaces, tabs, hidden characters, and line endings visible. Every preview page must be visited before applying a larger change. Conflicting choices require a combined preview that shows what will be reverted.

Keep original records a visibility-review decision without changing characters. Applied fixes can be reverted, undone, or redone. Reset decisions is also undoable. Any source change invalidates previous syntax and name results, so run Check syntax and names again after cleanup.

The inspector offers no automatic variable renaming. Correct a suspected typo in your source editor, then reinspect it. A name that looks misspelled may instead be supplied by a framework, another file, or a dynamic execution environment.

5. Save the reviewed Python copy

Copy cleaned source and Download cleaned .py use the same reviewed text. Downloads preserve UTF-8, the original BOM, and original newline sequences except for selected edits. A clipboard destination may normalize newlines. The abbreviated code display is not the downloaded file.

Export decision audit saves hashes, finding positions, offered edits, and cleanup history without the full original source. Replay requires the matching original and detector versions, and imported decisions are previewed before restoration. The audit is not a signed attestation or proof of correctness; syntax and name reports are not included in its version-1 format.

What the scanner can detect, explain, and not prove

The visibility scan can detect its documented character, punctuation, indentation, line-ending, and whitespace patterns. The compiler can explain the first syntax error in a complete file. The analyzer can identify some unresolved names, local uses before assignment, unused imports and variables, compiler warnings, a reviewed set of common mistakes, and code that is risky with untrusted input when syntax is valid.

The scanner can explain a reported observation and point you to the line, but it cannot prove why you intended the code, whether a suggested edit is correct, whether an import is installed, or whether a program will produce the intended result. Check the surrounding code and run your own tests in the intended environment.

Not supported: executing code, checking every project file, resolving packages from the internet, full type checking, security auditing, judging originality, or deciding whether code is allowed in a class. A clean result means no supported finding was reported, not that the code is safe or correct.

What this Python scanner does not check

This source inspector is not an antivirus scanner, a security audit, a full type checker, or a replacement for tests. Passing syntax does not validate package availability, attribute spelling, function-call signatures, every execution path, or intended results.

It currently inspects one selected source file at a time. It does not read folders, resolve imports across a project, inspect a virtual environment, install packages, or upload a project. A name or import that depends on another file therefore needs review in the intended project environment.

The compiler understands Python 3.14 syntax, but visibility detection inside formatted expressions remains conservative. Unicode confusable coverage is limited. Large analyses can be partial: visibility findings cap at 20,000, name and mistake findings cap at 1,000 per copy, compiler warnings cap at 200 per copy, and a syntax check has a 60-second deadline. Read coverage and unavailable notices instead of interpreting missing results as a clean bill of health.

Does the Python inspection upload or run my code?

A completed visibility inspection sends a content-free usage signal to this site so its dashboard can count inspections. The signal includes no source, filenames, findings, or variable names. It does not count unique people, and a failed signal does not interrupt inspection.

Inspect Code processes source in this browser, without uploading or executing it. Its runtime assets come from this application, and the workspace excludes site-wide analytics. This differs from the site's document-upload scanning workflow. The guide itself is a public informational page.

Keep your own original and reviewed files. Browser decisions are temporary; navigating away or closing the page can discard them. This guide describes the implemented workflow, not a guarantee of compatibility with every browser, Python version, or device.