# Supporto Python in Maguyva: ricerca IA sul codice e refactoring Canonical source: https://maguyva.ai/it/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 supporta Python con parsing AST ed estrazione dei simboli, aiutando gli agenti IA a seguire decoratori, metodi self/cls, import, e dipendenze tra moduli in repository Python reali. ## Istantanea del supporto - Livello: Supporto AST e simboli - Programmazione - Estensioni: .py, .pyi, .pyw - Analisi AST reale per ricerca sintattica e contesto strutturale. - I simboli nominati alimentano la ricerca semantica e i riferimenti incrociati. La navigazione del grafo è disponibile quando è abilitata l’estrazione delle relazioni. - Questo linguaggio contribuisce con simboli e relazioni alla ricerca basata sul grafo; i tipi di arco supportati variano in base ai suoi costrutti nativi. - Sono disponibili sia l’analisi AST sia l’estrazione dei simboli. ## Il più adatto per - Repository FastAPI, Django, data-platform, o tooling interno dove codice applicativo e script operativi convivono. - Team che fanno refactoring di servizi Python di lunga data che hanno già decoratori, job in background, e molto collegamento implicito. - Workflow ad agenti che hanno bisogno di più di grep prima di modificare un handler, service, model, o helper. ## Workflow degli agenti - Traccia un endpoint, un task, o un comando CLI attraverso helper e moduli condivisi prima di modificarlo. - Trova dove un service, una classe, o una funzione utility viene istanziata e riutilizzata nel repository. - Confronta implementazioni adiacenti così l'agente modifica l'astrazione giusta invece del match di stringa più vicino. ## Dove i repository Python di solito mandano in crisi gli strumenti IA superficiali Python è dove molti strumenti di coding IA sembrano buoni all'inizio e poi iniziano a indovinare in produzione. Le parti difficili sono familiari: punti di ingresso decorati, classi di servizio, stub di tipo, piccoli moduli helper ovunque, e metodi che hanno senso solo una volta ricollegati `self` o `cls` alla classe a cui appartengono. Per Python, la vera domanda non è "sa leggere i file `.py`?" La domanda è se l'agente riesca a restare ancorato mentre si sposta da un endpoint a un service, da un task in background a un helper, o da un nome di classe ai metodi che implementano davvero il comportamento. ## Cosa estrae davvero Maguyva in Python Maguyva offre un supporto completo all'analisi strutturale di Python. La configurazione copre `.py`, `.pyw`, e `.pyi`; mappa `decorated_definition` di nuovo a un simbolo di funzione; e qualifica le chiamate ai metodi tramite `self` / `cls` ricollegandole alla classe che le racchiude. Conta perché sono esattamente i punti dove i repository Python iniziano a sembrare ovvi per un essere umano e sfocati per un LLM. Filtra anche molto rumore della libreria standard dall'estrazione delle relazioni. Questo significa che le chiamate runtime comuni da moduli come `pathlib`, `typing`, o `logging` hanno meno probabilità di sommergere le relazioni specifiche del repository a cui tieni davvero. ## Workflow MCP utili per repository Python Il workflow utile più semplice è: - Inizia con `intelligent_search` per una domanda di comportamento come "logica di retry attorno alla sincronizzazione delle fatture" o "controlli dei permessi negli endpoint di fatturazione". - Passa a `find_symbol` una volta che conosci il nome della classe o della funzione a cui tieni. - Usa `dependency_search` con attraversamento in ingresso prima di rifattorizzare un service, un helper, o una base class condivisi. Quel pattern è meglio di chiedere a un agente di "aggiornare il flusso di fatturazione" partendo a freddo. Permette all'agente di costruire prima una mappa e modificare il codice dopo. ## Quando questa pagina è utile Questa pagina è per repository Python che hanno già una certa età e complessità: codice di servizio, job, script, tipi generati, e configurazione circostante. Se il tuo confronto principale riguarda i monorepo web poliglotti, leggi anche la [guida TypeScript](/it/languages/typescript). Se ti serve solo la matrice di supporto completa, usa [compatibilità](/it/docs/compatibility). ## Dettagli del motore - Le definizioni decorate sono comunque trattate come funzioni, quindi le view e i task decorati restano ricercabili come simboli. - Le chiamate ai metodi tramite `self` e `cls` vengono ricondotte alla classe che le contiene, il che aiuta il grafo a restare utile nel codice di servizio ricco di classi. - I normalizzatori di import, chiamate e simboli sono attivi mentre il rumore comune della stdlib come `pathlib.*`, `typing.*` e `logging.*` viene filtrato dalle relazioni. ## Punti di ingresso MCP utili - `intelligent_search`: Inizia con una query concettuale tipo “logica di retry attorno alla sincronizzazione delle fatture” e imposta `language_filter="python"` se il repository è poliglotta. - `find_symbol`: Usalo quando conosci il nome della classe o della funzione e ti serve la definizione più i riferimenti prima di modificare. - `dependency_search`: Usa la direzione in entrata prima di rifattorizzare un servizio o helper condiviso per vedere cosa ne dipende.