freerafiki
commented
4 years ago Mi pare molto confondente (come si dice in italiano? non confuso, ma che confonde, vabbè, mi capite) il modo in cui viene definito g e il modo in cui noi usiamo le variabili globali.
Flask usa diversi concetti di richiesta, contesto, applicazione, che forse dovremmo studiare meglio o almeno definire meglio nel nostro codice. Nel fare le API possiamo anche migliorare questa cosa. Non che non funzioni, ma almeno a me (prima di oggi) non era chiaro che funzionasse così.
Per capirci: chiamo richiesta una ricerca dell'utente, e il contesto della richiesta esiste solo mentre elaboriamo le informazioni cercate, poi muore. Questo è quello che viene salvato dentro la variabile g
Mi sembra che stiamo mischiando due cose: noi abbiamo due tipi di informazioni:
1 - informazioni che rimangono sempre uguali (path del file json per esempio) che non sono relativi a una richiesta (quindi non le metterei in g) e rimangono sempre uguali. Se le cambiamo, le cambiamo noi manualmente. Ora queste variabili sono definite in global_variables.py e ha senso perchè sono globali nel senso che sono comuni a tutto il codice ed è quello che vogliamo.
2 - informazioni che dipendono da quello che l'utente cerca (ponti, acqua, piedi, barca, off/on) che invece sono relative alla richiesta e cambiano. Queste vanno messe in g, come Ale ha fatto (ottimo punto, ci ho messo mille anni a capire sta cosa).
Conclusione:
La variabile g per me confonde moltissimo. La variabile si riferisce alla richiesta e vive nel contesto della richiesta.
Non è globale, e pertanto chiamarla g mi sembra terribile, ma tant'è. Armin (il creatore di Flask/Jinja) ne sa probabilmente più di noi.
Proposta:
Le nostre variabili globali in global_variables.py sono effettivamente quello che noi offline programmatori chiameremmo globali. La mia proposta è di considerare queste variabili come parametri del sito e salvarle in una tabella del database (proposta che avevo già avanzato, ma reitero dopo aver studiato di più). Non cambia nulla dal punto di vista pratico, ma mi sembra più semplice dal punto di vista concettuale e di debug. Se una variabile viene cambiata, viene cambiata per tutte le prossime richieste al sito, e sopravvive anche se la webapp viene ricaricata (forse questa è una differenza con usare il file python). In più non abbiamo più il nome globale e quindi facciamo meno confusione.
Le variabili della richiesta le salviamo su g, come ale ha già fatto, ora lo propago nel resto del codice. Io farei addirittura un attributo g.current_request e salverei tutto là (chiaramente nessun effetto sul codice python, solo sulla mia comprensione quando leggo), se non vi disturba.
Issue vera e propria Bisogna cambiare tutte le nostre variabili global (quelle ad esempio utilizzate nei calcoli dei pesi del grafo) in attributi dell'oggetto flask.g. Ho aggiunto in interface una funzione per salvare i vari dati in g giusto per averlo un po' ordinato e avere tutte le variabili globali là. Dalle altre funzioni basterà fare un
from flask import ge poi per accedere alla variabileg.la_tua_variabileSpiegazione TLDR: In generale non utilizzare le variabili global di python, ma utilizzare flask.g.
Con le variabili global in flask bisogna fare moltissima attenzione, perché essendo globali in generale sopravvivono alle singole request e quindi si possono creare conflitti e casini se ci sono vari utenti che fanno request in contemporane. Una delle tante spiegazioni qua. Per farla semplice (da quel che ho capito) in flask ci sono tre modi per definire variabili globali, ed ognuno di questi dovrebbe essere usato solo per il suo caso specifico: