Python Guidelines
Standards and best practices for Python development. Follow these guidelines when writing or modifying Python code.
Design Principles
Apply DRY, KISS, and SOLID consistently. Prefer functional methods where relevant; use classes for stateful behavior. Use composition with Protocol classes for interfaces rather than inheritance. Each module should have a single responsibility. Use dependency injection for class dependencies.
Code Style
- Naming: Descriptive yet concise names for variables, methods, and classes
- Documentation: Docstrings for all classes, functions, enums, enum values
- Type hints: Use consistently; avoid
Any unless necessary
- Imports: Avoid barrel exports in
__init__.py; prefer blank files
Type Annotations
- Use
dict, list instead of typing.Dict, typing.List
- Use
str | None instead of Optional[str]
- Include
from __future__ import annotations at top of files with type hints
- Prefer built-in types over typing module equivalents
Architecture
Dependency Injection
- Always inject dependencies via constructors or methods when using classes
- One service class per module (interface and class models allowed in addition)
- Use Protocol classes to define interfaces for dependency injection and testing
Module Organization
- Each module focuses on one concern with clear boundaries
- Extract reusable methods to avoid duplication
- Design for reusability across contexts
Environment Variables
- Use an
environment.py file with individual methods per variable (e.g., api_key() for API_KEY, database_url() for DATABASE_URL)
- Co-locate all environment access in one place per package for easier mocking in tests
Data Models
- Use Pydantic v2 for schemas, validation, and data models
- Leverage Pydantic's type validation, serialization, and configuration management
- Use Pydantic models for API request/response schemas, configuration objects, and data transfer objects
Testing
Structure
- Tests mirror
src/ directory structure
- Test methods start with
test_
- Use test class suites: for
def foo() create class TestFoo
- Keep names concise, omit class suite name from method
- Always check for appropriate unit tests when changing code
Quality
- Use AAA (Arrange, Act, Assert) pattern
- Tests should be useful, readable, concise, maintainable
- Avoid tests that create massive diffs or become burdensome
Tools
- Prefer
pytest over unittest
- Use
pytest-mock for mocking
- Use
conftest.py for shared fixtures
- Use
tests/__test_<package_name>__ for shared testing code
Implementation
When implementing Python code:
- Ensure code passes type checking and tests before committing
- Group related changes with tests in atomic commits
- Check for existing workflow patterns (spec-first, TDD, etc.) and follow them
References
- For adhoc Python scripts in uv-managed projects, see
references/uv-scripts.md.
- For monorepo-specific patterns using uv and Hatch, see
references/uv-monorepo.md.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: python-123description: Python development guidelines and best practices. Use when working with Python code. Use when this capability is needed.4---56# Python Guidelines78Standards and best practices for Python development. Follow these guidelines when writing or modifying Python code.910## Design Principles1112Apply DRY, KISS, and SOLID consistently. Prefer functional methods where relevant; use classes for stateful behavior. Use composition with Protocol classes for interfaces rather than inheritance. Each module should have a single responsibility. Use dependency injection for class dependencies.1314## Code Style1516- **Naming**: Descriptive yet concise names for variables, methods, and classes17- **Documentation**: Docstrings for all classes, functions, enums, enum values18- **Type hints**: Use consistently; avoid `Any` unless necessary19- **Imports**: Avoid barrel exports in `__init__.py`; prefer blank files2021## Type Annotations2223- Use `dict`, `list` instead of `typing.Dict`, `typing.List`24- Use `str | None` instead of `Optional[str]`25- Include `from __future__ import annotations` at top of files with type hints26- Prefer built-in types over typing module equivalents2728## Architecture2930### Dependency Injection3132- Always inject dependencies via constructors or methods when using classes33- One service class per module (interface and class models allowed in addition)34- Use Protocol classes to define interfaces for dependency injection and testing3536### Module Organization3738- Each module focuses on one concern with clear boundaries39- Extract reusable methods to avoid duplication40- Design for reusability across contexts4142### Environment Variables4344- Use an `environment.py` file with individual methods per variable (e.g., `api_key()` for `API_KEY`, `database_url()` for `DATABASE_URL`)45- Co-locate all environment access in one place per package for easier mocking in tests4647### Data Models4849- Use Pydantic v2 for schemas, validation, and data models50- Leverage Pydantic's type validation, serialization, and configuration management51- Use Pydantic models for API request/response schemas, configuration objects, and data transfer objects5253## Testing5455### Structure5657- Tests mirror `src/` directory structure58- Test methods start with `test_`59- Use test class suites: for `def foo()` create `class TestFoo`60- Keep names concise, omit class suite name from method61- Always check for appropriate unit tests when changing code6263### Quality6465- Use AAA (Arrange, Act, Assert) pattern66- Tests should be useful, readable, concise, maintainable67- Avoid tests that create massive diffs or become burdensome6869### Tools7071- Prefer `pytest` over `unittest`72- Use `pytest-mock` for mocking73- Use `conftest.py` for shared fixtures74- Use `tests/__test_<package_name>__` for shared testing code7576## Implementation7778When implementing Python code:7980- Ensure code passes type checking and tests before committing81- Group related changes with tests in atomic commits82- Check for existing workflow patterns (spec-first, TDD, etc.) and follow them8384## References8586- For adhoc Python scripts in uv-managed projects, see `references/uv-scripts.md`.87- For monorepo-specific patterns using uv and Hatch, see `references/uv-monorepo.md`.8889---90> Converted and distributed by [TomeVault](https://tomevault.io/claim/mgomes) — claim your Tome and manage your conversions.91<!-- tomevault:4.0:skill_md:2026-04-13 -->