louieQ
commented
3 years ago Ciao @RomitoVincenzo,
ti segnalo alcuni miglioramenti necessari e ti suggerisco qualche modifica da fare.
In linea generale, vorrei sapere da te se ritieni che ci sia qualche vantaggio nell'usare nbconvert. Se non ne trovi, potremmo analizzare direttamente i sorgenti in formato .json (credo sia il metodo che garantisce la massima flessibilità, anche nell'ottica di esaminare il markdown e altri eventuali tipi di celle).
Miglioramenti necessari
Dichiarazione delle dipendenze di progetto
Hai fatto bene a dichiarare le dipendenze del progetto nel file testEnv.yml; tuttavia mi sembra che tu stia lavorando in un ambiente anaconda che contiene tantissime librerie in più rispetto a quelle effettivamente usate nel tuo notebook. Questa cosa non va bene: se io volessi riprodurre il tuo ambiente d'esecuzione sulla mia macchina, dovrei installare giga e giga di dipendenze inutilmente.
Dovresti creare un nuovo ambiente - assicurandoti di installarvi solo lo stretto necessario - e, a partire da questo ambiente "pulito", ricreare il file testEnv.yml con la dichiarazione delle dipendenze reali.
Attieniti al "Single Responsibility Principle"
Ogni funzione dovrebbe assolvere uno e un solo compito.
Una funzione come FunctionNumberNbTree, che analizza il codice Python per trovare il numero di definizioni di funzione ivi contenute, dovrebbe ricevere in input una stringa con il codice da analizzare ed emettere in output il risultato. La lettura del file .ipynb e la relativa conversione vanno fatte all'esterno, per mezzo di altre funzioni.
Si possono sempre costruire funzioni più astratte che eseguono in pipeline le funzioni elementari, ma al livello a cui siamo non è ancora il caso. Queste che hai definito sono tutte funzioni che dovrebbero avere una singola responsabilità.
Suggerimenti di minore importanza
- Nel codice, all'interno delle definizioni di funzione, hai fatto molto bene a lasciare commenti che ne spieghino lo scopo e il funzionamento. Tali commenti, tuttavia, dovrebbero essere riportati nella forma di Python docstrings per agevolare la costruzione automatica di una documentazione di progetto. Ad es:
def notebookToPyCodeLoad(filename): """The function takes the name of the desired .ipynb file in the target notebooks folder and returns a python code string""" - Sfrutta la sintassi Markdown nelle celle testuali: all'interno del tuo notebook, i titoli sono riportati come testo semplice. Aggiungendo un cancelletto (o più d'uno, a seconda del livello) puoi marcarli come headings; di conseguenza verranno stampati più in grande.
- Il file in cui vengono dichiarate le dipendenze per mezzo di
condaviene solitamente denominatoenvironment.yml. Conviene seguire le convenzioni di file naming per rendere più facilmente riconoscibili le risorse all'interno di un repository.
RomitoVincenzo
Nel branch codeExtraction puoi trovare diverse funzioni di estrazione del codice Pyton e numerazione delle definizioni di funzione presenti così come mi avevi chiesto. Ho esplorato sia la soluzione con la deserializzazione, sia quella NBconvert e sia quella di parse tree. Sono 2-3 alternative che fanno la stessa cosa, le ho sviluppate e commentate in modo che potessi dare una occhiata e magari decidere quale fosse l'approccio migliore. I nomi delle funzioni sono stati scritti in modo da far comprendere quale fosse l'implementazione, per agevolare il tuo lavoro nella review, ovviamente nel momento in cui si decide quale implementazione si vuole utilizzare tra quelle che ho sviluppato si andranno a modificare gli identificatori per renderli più chiari e aprirei una pull request per il merge. Se hai bisogno di discuterle sono a tua disposizione.