python-patterns

maxbeworks's avatarfrom maxbeworks

Python coding style - pragmatic, readable, fast development over heavy abstraction

⭐0stars🔀0forks📁View on GitHub🕐Updated Jan 8, 2026
[Code Generation]

When & Why to Use This Skill

This Claude skill optimizes Python development by enforcing a pragmatic, readability-first coding style. It streamlines the development process by prioritizing speed and clarity over heavy abstractions, ensuring that generated code is efficient, easy to maintain, and free from common over-engineering anti-patterns.

Use Cases

  • Rapid Prototyping: Quickly generate functional MVPs and proof-of-concept scripts without the overhead of complex architectures or unnecessary boilerplate.
  • Code Refactoring: Simplify over-engineered Python codebases by removing excessive abstraction layers and replacing them with clean, readable, and 'Pythonic' logic.
  • Scripting and Automation: Develop lightweight internal utilities and data scraping scripts where development speed and immediate readability are more valuable than strict type annotations.
  • API Development: Create efficient API endpoints and request/response models using Pydantic and typing only where it adds tangible value for validation and stability.
namepython-patterns
descriptionPython coding style - pragmatic, readable, fast development over heavy abstraction

Philosophy

  • Python is for quick and dirty solutions - prioritize speed and readability over abstraction layers
  • Don't overcomplicate with rarely-used built-in methods or excessive safety measures
  • Write code that's easy to read and understand, not "clever"

Readability and Style

  • Use one-liners when they're clear and simple
  • Break into multiple lines when complexity makes it hard to parse
  • Best judgment on what's "too complex" - if you have to think twice, split it
  • Prefer explicit over implicit when it improves clarity

Type Annotations

  • Only use typing and Pydantic when truly necessary
  • API endpoints, request/response models - yes, type these
  • Internal utility functions, scraping scripts, quick tools - skip typing unless it adds real value
  • Don't type just because "best practices" say so - use judgment based on whether the code is static/stable

Error Handling

  • Never use bare except: - always specify exception types
  • Handle specific exceptions you expect, let others bubble up
  • Early returns for error cases

Class Design

  • Prefix internal methods with _ (single underscore) when they're only meant for internal class use
  • Keep classes simple - don't create unnecessary hierarchies
  • Composition over inheritance when it makes sense

Code Organization

  • Keep functions focused but don't obsess over single responsibility
  • Split when readability suffers, not by arbitrary rules
  • Colocate related functionality
  • Flat is better than nested

Anti-Patterns

  • Over-engineering with abstract base classes and complex inheritance
  • Type hints on everything just to have them
  • Deeply nested comprehensions that require mental gymnastics
  • Magic methods unless you have a damn good reason
  • Creating classes when simple functions would work fine