Cursor Rules: Python — Clean Code with AI

What it is

This is a set of Cursor rules tailored for Python development. It configures Cursor's AI assistant to enforce PEP 8 style, type hints, docstrings, pytest patterns, and modern Python 3.12+ idioms when generating or editing Python code.

Python developers using Cursor as their AI-assisted IDE benefit from these rules by getting consistently clean, idiomatic code suggestions without manually correcting style violations after every generation.

How it saves time or tokens

Without rules, AI code assistants generate code that varies in style and quality. You spend tokens on follow-up prompts asking for type hints, docstrings, or style corrections. These Cursor rules front-load those preferences, so the first generation matches your standards. Fewer correction rounds means fewer tokens consumed.

How to use

1. Copy the rules configuration into your project's .cursorrules file.
2. Open the project in Cursor and start coding. The AI assistant will follow the rules automatically.
3. Adjust rules as needed for project-specific conventions (framework preferences, test style).

Example

{
  "rules": [
    "Always use type hints for function parameters and return values",
    "Follow PEP 8 naming: snake_case for functions and variables, PascalCase for classes",
    "Write Google-style docstrings for all public functions",
    "Use pytest fixtures instead of setUp/tearDown methods",
    "Prefer pathlib.Path over os.path for file operations",
    "Use f-strings for string formatting, never % or .format()",
    "Use match/case for complex conditionals (Python 3.10+)",
    "Import from __future__ import annotations for forward references"
  ]
}

Related on TokRepo

• AI Tools for Coding — AI-powered coding assistants and developer tools
• Prompt Library — Curated prompts and rules for AI workflows

Common pitfalls

• Making rules too specific to one framework, which confuses the AI when you work on non-framework code in the same project.
• Adding contradictory rules (e.g., 'always use classes' and 'prefer functional style') that produce inconsistent output.
• Not testing rules with actual code generation to verify they produce the expected behavior.