nccgroup/call_mapLo sviluppo attuale di Call Map avviene su https://github.com/ajylee/call_map. Call Map è uno strumento per navigare i grafi delle chiamate in Python.
.. default-role:: code
Call Map è uno strumento per navigare i grafi di chiamata in Python, con l'intenzione di supportare
altri linguaggi. Di seguito è mostrata una schermata dopo aver eseguito call_map -m toolz e aver
fatto clic su alcune funzioni.
.. figure:: docs/UI-clicked-on-function.png
Sebbene Call Map sia pensato per aiutare ad acquisire una comprensione generale di un codebase, si presta naturalmente anche al tracciamento dei percorsi del codice, che costituisce un'importante questione di sicurezza. Molti problemi di sicurezza emergono individuando un percorso del codice che collega l'input dell'utente a pattern di codice pericolosi.
Vedi il post sul blog__ per maggiori informazioni.
Call Map è distribuito come pacchetto Python per Python 3.5. Per installarlo con
pip3, esegui::
pip3 install -e .
Nota che alcune distribuzioni di Python 3 chiamano il gestore dei pacchetti pip, mentre altre
lo chiamano pip3, quindi potrebbe essere necessario sostituire pip3 con pip.
I comandi precedenti dovrebbero installare l'eseguibile call_map nello stesso percorso
in cui si trova l'interprete Python.
Per maggiori dettagli e metodi alternativi, vedere INSTALL.rst.
Apri i file per iniziare a esplorare::
call_map -f example.py
call_map -f *.py
Puoi anche aggiungere al percorso di ricerca dei moduli (sys.path)::
call_map -f *.py -p .
Call Map proverà a risolvere i file come moduli ogni volta che possono essere trovati nel
percorso di ricerca dei moduli. Per ulteriore documentazione sugli argomenti
da riga di comando, call_map -h.
Per configurare Call Map, imposta la variabile d'ambiente CALL_MAP_RC_DIRECTORY. Il percorso del file di configurazione di Call Map sarà::
$CALL_MAP_RC_DIRECTORY/call_map_rc.py
Al momento le opzioni di configurazione sono:
open_in_editor(path: pathlib.Path, line: int): se definisci questa funzione
verrà chiamata ogni volta che apri un file. Ad esempio, quanto segue può essere
usato per aprire file in un server Emacs se hai chiamato server-mode in una
sessione Emacs in esecuzione::
def open_in_editor(path, line): import subprocess as sbp sbp.call(['emacsclient', '+{}'.format(line), str(path)])
Quanto segue può essere usato per aprire file nel server GVim se hai avviato un server GVim
con gvim --servername my_vim_server::
def open_in_editor(path, line): import subprocess as sbp sbp.call(['gvim', '--servername', 'my_vim_server', '--remote', '+{}'.format(line), str(path)])
MULTITHREADING: se usare un thread separato per la GUI e la ricerca
del grafo delle chiamate. Il valore predefinito è True. Disattivarlo serve a scopo di debug.
Ci sono un paio di stranezze nella progettazione dell'interfaccia, dovute al fatto che non sono giunto a una soluzione migliore o che il compromesso di una maggiore complessità è sfavorevole.
Gli usi possono sembrare presenti più di una volta, ma in realtà sono usi diversi nello stesso scope.
Potresti notare che alcuni built-in come help, id e filter vengono ignorati.
Vedi call_map/config.py nel codice sorgente per l'elenco completo delle funzioni
ignorate.
Se la posizione da evidenziare è all'inizio di un file, non verrà evidenziata. Questo perché in genere solo i moduli e gli script si trovano all'inizio dei rispettivi file.
Alcune stranezze sono ereditate dal backend jedi di analisi Python.
L'ambito di ricerca per gli usi è l'insieme dei moduli caricati dal
backend jedi. Ciò significa che l'ambito cambierà man mano che esplori nuovi
moduli. Se vuoi includere esplicitamente un modulo nell'ambito di ricerca, aggiungilo
all'elenco iniziale dei moduli da ispezionare.
jedi cerca sempre nel sys.path dell'interprete, anche quando non
è incluso esplicitamente. Tuttavia, darà priorità al sys_path definito dall'utente.
Qualsiasi avvertenza valida per i backend di analisi statica si applica anche a Call Map. (Al
momento solo il backend jedi è integrato in Call Map.)
Il backend jedi per l'analisi Python non trova sempre tutti gli usi. La
natura dinamica di Python rende impossibile determinare sempre la definizione
di una funzione con l'analisi statica. A volte jedi risolve una chiamata in più
funzioni possibili. Ad esempio os.path.abspath dipende dalla piattaforma. In
questo caso call_map elenca entrambe le possibilità come abspath e abspath (2).
jedi inoltre non risolve tutte le chiamate e tutti gli usi. Anche la documentazione di Jedi
ha una lista di avvertenze__.
A volte, quando Jedi solleva un errore durante l'analisi di un elemento, l'errore influisce su altri elementi. Ad esempio, quando si cercano gli usi, se Jedi solleva un errore su un uso, gli altri usi che ha trovato potrebbero essere irrecuperabili (a partire da Jedi v0.10.0).
__ https://jedi.readthedocs.io/en/latest/docs/features.html#caveats
