# Prise en charge de Python dans Maguyva : recherche de code et refactorisation par IA

Canonical source: https://maguyva.ai/fr/languages/python

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Maguyva prend en charge Python avec analyse AST et extraction de symboles, aidant les agents IA à suivre les décorateurs, les méthodes self/cls, les imports et les dépendances inter-modules dans de véritables dépôts Python.

## Aperçu du support

- Palier: Prise en charge de l’AST et des symboles
- Programmation
- Extensions: .py, .pyi, .pyw
- Analyse AST réelle pour une recherche consciente de la syntaxe et un contexte structurel.
- Les symboles nommés alimentent la recherche sémantique et le référencement croisé. La navigation par graphe est disponible lorsque l’extraction de relations est activée.
- Ce langage fournit des symboles et des relations à la recherche tenant compte du graphe ; les types d’arêtes pris en charge varient selon ses constructions natives.
- L’analyse AST et l’extraction de symboles sont toutes deux disponibles.

## Idéal pour

- Les dépôts FastAPI, Django, plateforme de données ou outillage interne où code applicatif et scripts opérationnels cohabitent.
- Les équipes qui refactorisent des services Python de longue durée disposant déjà de décorateurs, de tâches de fond et de beaucoup de câblage implicite.
- Les flux de travail d'agent qui ont besoin de plus qu'un grep avant de modifier un handler, un service, un modèle ou un utilitaire.

## Workflows d'agent

- Tracer un point d'accès, une tâche ou une commande CLI à travers les utilitaires et modules partagés avant de la modifier.
- Trouver où un service, une classe ou une fonction utilitaire est instancié et réutilisé dans le dépôt.
- Comparer des implémentations voisines pour que l'agent modifie la bonne abstraction plutôt que la correspondance textuelle la plus proche.

## Là où les dépôts Python mettent en échec les outils IA superficiels

Python est l'endroit où beaucoup d'outils de codage IA paraissent bons au premier abord, puis se mettent à deviner une fois en production. Les difficultés sont familières : points d'entrée décorés, classes de service, stubs de types, petits modules utilitaires partout, et méthodes qui ne prennent sens qu'une fois `self` ou `cls` reconnectés à la classe à laquelle ils appartiennent.

Pour Python, la vraie question n'est pas « peut-il lire les fichiers `.py` ? ». La question est de savoir si l'agent peut rester ancré tandis qu'il passe d'un point d'accès à un service, d'une tâche de fond à un utilitaire, ou d'un nom de classe aux méthodes qui implémentent réellement le comportement.

## Ce que Maguyva extrait réellement en Python

Maguyva assure une prise en charge structurelle complète de Python. La configuration couvre `.py`, `.pyw` et `.pyi`, fait remonter `decorated_definition` vers un symbole de fonction, et qualifie les appels de méthode `self` / `cls` en les rattachant à la classe englobante. Cela compte, car ce sont précisément les endroits où les dépôts Python commencent à paraître évidents pour un humain et flous pour un LLM.

Il filtre aussi une grande partie du bruit de la bibliothèque standard hors de l'extraction de relations. Cela signifie que les appels d'exécution courants issus de modules comme `pathlib`, `typing` ou `logging` ont moins de chances de noyer les relations propres au dépôt qui vous intéressent réellement.

## Flux de travail MCP utiles pour les dépôts Python

Le flux de travail utile le plus simple est le suivant :

- Commencez par `intelligent_search` pour une question de comportement telle que « logique de nouvelle tentative autour de la synchronisation des factures » ou « vérifications de permissions dans les points d'accès de facturation ».
- Passez à `find_symbol` une fois que vous connaissez le nom de la classe ou de la fonction qui vous intéresse.
- Utilisez `dependency_search` avec un parcours entrant avant de refactoriser un service, un utilitaire ou une classe de base partagés.

Ce schéma vaut mieux que de demander à un agent de « mettre à jour le flux de facturation » à froid. Il permet à l'agent de construire d'abord une carte, puis de modifier le code ensuite.

## Quand cette page est utile

Cette page s'adresse aux dépôts Python qui ont déjà un certain âge et une certaine complexité : code de service, tâches, scripts, types générés et configuration environnante. Si votre comparaison principale porte sur des monorepos web polyglottes, lisez aussi le [guide TypeScript](/fr/languages/typescript). Si vous avez seulement besoin de la matrice complète de compatibilité, consultez [compatibilité](/fr/docs/compatibility).

## Détails du moteur

- Les définitions décorées sont toujours traitées comme des fonctions, donc les vues et tâches décorées restent recherchables comme symboles.
- Les appels de méthode `self` et `cls` sont qualifiés en les rattachant à la classe englobante, ce qui aide le graphe à rester utile dans le code de service riche en classes.
- Les normaliseurs d'import, d'appel et de symbole sont activés, tandis que le bruit courant de la stdlib comme `pathlib.*`, `typing.*` et `logging.*` est filtré des relations.

## Points d'entrée MCP utiles

- `intelligent_search`: Commencez par une requête conceptuelle comme « logique de retry autour de la synchro des factures » et définissez `language_filter="python"` si le dépôt est polyglotte.
- `find_symbol`: Utilisez-le quand vous connaissez le nom de la classe ou de la fonction et avez besoin de la définition plus les références avant de modifier.
- `dependency_search`: Utilisez la direction entrante avant de refactoriser un service ou un helper partagé pour voir ce qui en dépend.