Loading...
Loading...
Guidance on Python code style optimization and Pythonic idioms; Based on the complete content of *One Python Craftsman* and the "Friendly Python" concept, covering variable naming, control flow, data types, container types, function design, exception handling, decorators, file operations, and SOLID principles; Providing user-friendly and maintainer-friendly design patterns, review checklists, and over 140 practical templates
npx skill4agent add morning-start/coze-skills pythonic-style┌──────────────────────────────────────────────────────────┐
│ FRIENDLY PYTHON = User-Friendly Python │
├────────────────────────────────┬─────────────────────────┤
│ User-Friendly │ Maintainer-Friendly │
│ ───────────────── │ ───────────────── │
│ • Sensible defaults │ • Single change point │
│ • Minimal required params │ • Registry over if-else│
│ • Hidden resource mgmt │ • Explicit over magic │
│ • Simple → complex path │ • Readable & debuggable│
└────────────────────────────────┴─────────────────────────┘classmethod__init____getattr__┌─────────────────────────────────────────────────────────────┐
│ 1. UNDERSTAND: Understand requirements and existing code │
├─────────────────────────────────────────────────────────────┤
│ 2. ANALYZE: Analyze code style issues and identify non-Pythonic patterns │
├─────────────────────────────────────────────────────────────┤
│ 3. IMPROVE: Apply Pythonic idioms and design patterns │
├─────────────────────────────────────────────────────────────┤
│ 4. REVIEW: Check improvement plans against review checklists │
├─────────────────────────────────────────────────────────────┤
│ 5. REFINE: Optimize details and provide alternative solutions and trade-off analysis │
└─────────────────────────────────────────────────────────────┘| Check Item | Question |
|---|---|
| 🔧 Extensibility | Does adding new features only require modifying one place in the code? |
| 🎯 Default Values | Does the API have reasonable default values? Are unnecessary objects hidden? |
| 📈 Complexity | Does complexity follow "simple to complex", and is the default path the lightest? |
| 🔌 Extension Points | Are ecosystem extension points prioritized? |
| 👁️ Explicitness | Is explicitness and maintainability sacrificed for showing off skills? |
| 🔄 Ported Code | Was the calling pattern redesigned when porting code? |
| Scenario | Recommended Practice |
|---|---|
| Multiple implementation methods | Registry pattern + decorator registration |
| Resource management | Context manager ( |
| Multiple input sources | |
| Configuration fields | Descriptors |
| Extending third-party libraries | Official extension points (hook/adapter/auth) |
| Asynchronous operations | async/await + try/except/finally |
| CLI tools | argparse + Command class |
| Complex object construction | Builder pattern |
| Strategy selection | Registry/dictionary lookup |
| Circular imports | Lazy import/refactor modules |
| Anti-Pattern | Problem |
|---|---|
| A large number of if-else branches | Adding features requires modifying multiple places |
Using flags to control paths in | Mutually exclusive parameters are unclear |
| Weakens discoverability and type checking |
| Overuse of metaclasses | Pollutes users' mental models |
| Custom wrapping of original libraries | Duplicate attributes, maintenance burden |
| JS-style callbacks | Not Pythonic |
| Global state | Difficult to test and maintain |
| Over-inheritance | Composition over inheritance |
| Hard-coded configuration | Lack of flexibility |
| Bare except | Swallows all exceptions |
## Summary
[Summary of completed work]
## Changes Made
- [Improvement 1]: [Explanation]
- [Improvement 2]: [Explanation]
## Design Decisions
- [Why certain patterns were chosen]
## Review Checklist
- [x] Single-point extensibility
- [x] Reasonable default values
- [x] Progressive complexity
- [x] Correct use of extension points
- [x] Explicitness over magic
## Suggestions (if any)
- [Areas for further improvement]assets/templates/