
Python Patterns
Invoke when choosing Python frameworks, async vs sync design, typing, and project layout before you commit code.
Overview
Python Patterns is an agent skill most often used in Build (also Validate, Ship) that guides framework, async, typing, and project-structure decisions for Python products.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill python-patternsWhat is this skill?
- Framework decision tree: FastAPI, Django, Flask, Celery workers by product shape
- Explicit rule: ask the user for framework preference—do not default blindly
- Async vs sync and ORM selection taught as context-driven principles
- Comparison table across FastAPI, Django, and Flask for 2025 decisions
- Teaches decision-making, not copy-paste snippets
- Framework decision tree covers API-first, full-stack, simple scripts, AI/ML serving, and background workers
- FastAPI vs Django vs Flask comparison table in SKILL.md
Adoption & trust: 938 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are starting or refactoring Python services but lack a consistent way to choose frameworks and async design without cargo-culting one stack.
Who is it for?
Indie builders shipping APIs, admin apps, or worker-backed SaaS who want principled Python architecture dialogue with their agent.
Skip if: Teams that already locked a corporate standard stack and only need syntax snippets, or non-Python greenfield work.
When should I use this skill?
Use this skill when making Python architecture decisions, choosing frameworks, designing async patterns, or structuring Python projects.
What do I get? / Deliverables
You leave with a context-backed framework choice, async/sync stance, and structural plan aligned to what you are actually building.
- Documented framework and async/sync recommendation
- Agreed high-level Python project structure
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Primary shelf is Build backend because architecture and framework choices land when you are implementing services and APIs. Backend subphase covers API-first stacks (FastAPI), full-stack Django, and worker patterns that define how your product core is structured.
Where it fits
Decide whether your MVP should be API-first FastAPI or Django admin-heavy before you estimate build time.
Pick async endpoints and Pydantic models for an AI inference API serving layer.
Re-check whether synchronous code paths should move async before load testing.
Evaluate adding Celery workers without rewriting the whole web framework choice.
How it compares
Use instead of asking the model for generic FastAPI tutorials—this skill forces tradeoff reasoning across Django and Flask too.
Common Questions / FAQ
Who is python-patterns for?
Solo and small-team builders making Python backend and service architecture decisions with coding agents.
When should I use python-patterns?
Use during Validate scoping when picking a stack, during Build backend implementation, and during Ship review when revisiting async and ORM choices before release.
Is python-patterns safe to install?
It is documentation-only procedural guidance; review the Security Audits panel on this page and treat any generated code as yours to audit.
SKILL.md
READMESKILL.md - Python Patterns
# Python Patterns > Python development principles and decision-making for 2025. > **Learn to THINK, not memorize patterns.** ## When to Use Use this skill when making Python architecture decisions, choosing frameworks, designing async patterns, or structuring Python projects. --- ## ⚠️ How to Use This Skill This skill teaches **decision-making principles**, not fixed code to copy. - ASK user for framework preference when unclear - Choose async vs sync based on CONTEXT - Don't default to same framework every time --- ## 1. Framework Selection (2025) ### Decision Tree ``` What are you building? │ ├── API-first / Microservices │ └── FastAPI (async, modern, fast) │ ├── Full-stack web / CMS / Admin │ └── Django (batteries-included) │ ├── Simple / Script / Learning │ └── Flask (minimal, flexible) │ ├── AI/ML API serving │ └── FastAPI (Pydantic, async, uvicorn) │ └── Background workers └── Celery + any framework ``` ### Comparison Principles | Factor | FastAPI | Django | Flask | |--------|---------|--------|-------| | **Best for** | APIs, microservices | Full-stack, CMS | Simple, learning | | **Async** | Native | Django 5.0+ | Via extensions | | **Admin** | Manual | Built-in | Via extensions | | **ORM** | Choose your own | Django ORM | Choose your own | | **Learning curve** | Low | Medium | Low | ### Selection Questions to Ask: 1. Is this API-only or full-stack? 2. Need admin interface? 3. Team familiar with async? 4. Existing infrastructure? --- ## 2. Async vs Sync Decision ### When to Use Async ``` async def is better when: ├── I/O-bound operations (database, HTTP, file) ├── Many concurrent connections ├── Real-time features ├── Microservices communication └── FastAPI/Starlette/Django ASGI def (sync) is better when: ├── CPU-bound operations ├── Simple scripts ├── Legacy codebase ├── Team unfamiliar with async └── Blocking libraries (no async version) ``` ### The Golden Rule ``` I/O-bound → async (waiting for external) CPU-bound → sync + multiprocessing (computing) Don't: ├── Mix sync and async carelessly ├── Use sync libraries in async code └── Force async for CPU work ``` ### Async Library Selection | Need | Async Library | |------|---------------| | HTTP client | httpx | | PostgreSQL | asyncpg | | Redis | aioredis / redis-py async | | File I/O | aiofiles | | Database ORM | SQLAlchemy 2.0 async, Tortoise | --- ## 3. Type Hints Strategy ### When to Type ``` Always type: ├── Function parameters ├── Return types ├── Class attributes ├── Public APIs Can skip: ├── Local variables (let inference work) ├── One-off scripts ├── Tests (usually) ``` ### Common Type Patterns ```python # These are patterns, understand them: # Optional → might be None from typing import Optional def find_user(id: int) -> Optional[User]: ... # Union → one of multiple types def process(data: str | dict) -> None: ... # Generic collections def get_items() -> list[Item]: ... def get_mapping() -> dict[str, int]: ... # Callable from typing import Callable def apply(fn: Callable[[int], str]) -> str: ... ``` ### Pydantic for Validation ``` When to use Pydantic: ├── API request/response models ├── Configuration/settings ├── Data validation ├── Serialization Benefits: ├── Runtime validation ├── Auto-generated JSON schema ├── Works with FastAPI natively └── Clear error messages ``` --- ## 4. Project Structure Principles ### Structure Selection ``` Small project / Script: ├── main.py ├── utils.py └── requirements.txt Medium API: ├── app/ │ ├── __init__.py │ ├── main.py │ ├── models/ │ ├── routes/ │ ├── services/ │ └── schemas/ ├── tests/ └── pyproject.toml Large application: ├── src/ │ └── myapp/ │ ├── core/ │ ├── api/ │ ├── services/ │