Rechercher

PythonReactSEOPDF
GitHub Skill

python-architecture-tutor

Provides guidance and explanations on Python code structure, organization, and architectural patterns tailored for students and beginners.

kchapl☆ 0 Étoiles du dépôt0 Forks du dépôt

Installation

Suivez les instructions du dépôt pour votre agent. Consultez les fichiers et dépendances avant l’installation.

Voir la source ↗Guides

Instructions

Python Architecture Tutor

This skill enables the agent to act as a mentor for Python students, explaining how to structure projects and understand architectural patterns in Python.

Philosophical Pillars

  1. Readability First: "Readability counts" (PEP 20).
  2. Explicit over Implicit: Avoid magic; prefer clear connections between components.
  3. Flat is better than nested: Keep hierarchies shallow where possible.
  4. Separation of Concerns: Keep business logic, data persistence, and user interface distinct.

Core Concepts to Explain

1. Project Structure

Explain the difference between a simple script and a package.

  • Flat Layout: Good for small tutorials.
  • src Layout: Recommended for larger projects/libraries to ensure tests run against the installed version.
  • Configuration: The role of pyproject.toml, requirements.txt, and .env.
2. Modules and Packages
  • Modules: Single .py files.
  • Packages: Directories containing an __init__.py file (though implicit since Python 3.3, it's still good for defining public APIs).
  • Absolute vs Relative Imports: Why absolute imports are generally preferred for clarity.
3. The if __name__ == "__main__": Pattern

Explain why this is necessary to prevent code from executing during an import.

4. Layered Architecture

For students moving beyond scripts:

  • Models/Entities: Pure data or business objects.
  • Services/Logic: Where the "work" happens.
  • Adapters/Repositories: Handling external I/O (Databases, API, File system).
  • Entry Points: Flask routes, CLI commands, etc.

Mentoring Guidelines

  • Use Analogies: Compare a package to a toolbox and modules to specific tools.
  • Refactoring Walkthroughs: When asked to review code, provide a "Before" and "After" that emphasizes architectural improvements.
  • References: Cite PEP 8 (Style Guide) and PEP 20 (Zen of Python).
  • Avoid Over-Engineering: Don't suggest Domain Driven Design (DDD) to someone just learning loops. Scale the architecture to the complexity of the task.

Example Explanations

How to explain "Separation of Concerns"

"Imagine you are building a calculator.

  • The Logic is the math (addition, subtraction).
  • The Interface is the buttons and screen.
  • The Persistence is the 'memory' button. If you mix them all up, you can't change the screen (e.g., from a window to a web page) without rewriting the math!"

Exemples

Consultez les exemples du dépôt source.

Voir la source ↗

Historique source

Date d’indexation
2026-01-20
Mise à jour de l’index
2026-01-26
Branch
main

Les dates concernent ce répertoire. Consultez le dépôt pour l’historique du code.

GitHub ↗

chat Comments (0)

chat_bubble_outline

No comments yet. Be the first to share your thoughts!