Visualizza post

Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.


Post - RicPol

Pagine: [1] 2 3 ... 218
1
Base / Re:Storage parametri applicazione : un consiglio
« il: Aprile 23, 2019, 23:06 »
> Leggersi il s.o., quindi, poi regolarsi.
Oppure usare una roba come questa https://github.com/ActiveState/appdirs ma bisogna leggere il codice per bene e capire se fidarsi.

2
Base / Re:Storage parametri applicazione : un consiglio
« il: Aprile 23, 2019, 14:26 »
Su Windows la policy è chiara (magari non seguita, ma...): in %ALLUSERSPROFILE%\\myapp i dati non user-dependent dell'applicazione (se ha senso), in %LOCALAPPDATA%\\myapp (o al massimo in %APPDATA%\\myapp) i dati dell'utente. E più in generale, https://docs.microsoft.com/it-it/windows/desktop/shell/knownfolderid.
Poi per fare questo sarebbe buona educazione fornire anche un installer/uninstaller che pulisce correttamente i vari pezzetti lasciati in giro...
Se però si trattta del solito programmino distribuito alla selvaggia, allora è di gran lunga preferibile usare una sub-directory "interna" all'applicazione e tenere tutto quanto il più vicino possibile senza spargere cose in giro.

In Linux in effetti.... la situazione è più sfumata. Eh.

La parola "nascosta" è ovviamente priva di significato in questo contesto, come è stato detto mille volte. Non puoi nascondere nulla sulla macchina di proprietà di un altro.

3
Database / Re:JSON o SQLite
« il: Aprile 14, 2019, 11:31 »
Troppe poche informazioni. Messa così, la risposta è: è assolutamente indifferente, non ci sono pro o contro per preferire nessuna delle due ipotesi. Se al momento non hai nessuna prospettiva più specifica per quello che effettivamente dovrà accadere nella tua applicazione, allora il mio consiglio è di tirare una monetina e usare indifferentemente uno dei due metodi di persistenza. Se poi in futuro capirai di aver pescato quello sbagliato, cambierai. L'importante è che il layer del tuo codice che si occupa della persistenza esponga un'API verso il resto del codice che maschera il meccanismo di persistenza, in modo tale che se in futuro dovessi cambiarlo, il resto del codice non ne sarebbe affetto.

4
Base / Re:lavorare con le immagini
« il: Febbraio 18, 2019, 13:37 »
Sì beh certo, "ragionando" puoi derivare daccapo la meccanica quantistica partendo dalla quattro operazioni. Però non è una cosa che lascerei fare come esercizio ai miei allievi, diciamo. Vabbè, rinuncio a esprimere ancora una volta la mia consueta opinione sulla qualità dell'insegnamento universitario in Italia. Fatti una googlata per "python flood fill", o cerca "flood fill" su wikipedia, e vedi cosa riesci a mettere insieme.

5
Base / Re:lavorare con le immagini
« il: Febbraio 18, 2019, 13:00 »
Mah sai non è che sia "banale" o "difficile"... quando vedo esercizi come questo, mi chiedo sempre quanto è progressiva la curva di apprendimento che ci sta dietro. Cioè, è un esercizio che hai pescato tirando a sorte da una raccolta di esercizi, o te lo hanno dato nell'ambito di un corso? Perché in questo caso non riesco a credere che non ti abbiano anche già dato qualche strumento intermedio per ragionarci su.
Per esempio, questo esercizio diventa "banale" (più o meno) se hai un'idea di come funziona un algoritmo "flood fill". E siccome questi algoritmi di solito usano strutture-dati come le Queue, ancora prima dovresti avere un'idea di che cosa è una Queue e come funziona... Certo se il tuo livello di conoscenza pregressa è ancora del tipo "liste e funzioni col print in fondo", questo esercizio diventa un monte Everest da scalare.

6
Base / Re:Ottimizzazione del codice
« il: Febbraio 13, 2019, 22:08 »
Avrei due suggerimenti.

Il primo è di rendere più ottimizzato e pythonico NON il tuo codice, ma per cominciare questo tuo post. "Mi permette di gestire la classe compress e uncompress e di implementare gli script" EEEHHH????? Scusa che cosa dovremmo sapere noi, che non ci stai dicendo? Tu dai per scontato che chi legge magia a colazione pane e src.converter, e beve acqua e src.Compress (con la lettera maiuscola... boh). Non so gli altri, ma io non ho la più pallida idea di che cosa si suppone che questo codice debba fare, con quali librerie deve lavorare, etc. Se non fornisci un (bel) po' di contesto, non è che abbiamo la sfera di cristallo.

Il secondo consiglio è questo: se vuoi ottimizzare e rendere più pythonico quel codice, aspetta sei mesi senza toccarlo, senza leggerlo, facendo altro. Altre cose, altro codice, altri pensieri, altri progetti. Poi, il 13 agosto sotto l'ombrellone prova a rileggerlo e vedi quello che riesci a capire. Lo shock di quello che scoprirai ti porterà sicuramente a ottimizzare il codice e renderlo più pythonico. A partire da un rispetto totale della Pep8, e da una documentazione ossessiva.

7
pyGTK / Re:Monitoraggio attività app
« il: Febbraio 12, 2019, 21:44 »
"Non ci sono attività in corso" è un'impressione soggettiva che puoi determinare solamente tu. Per esempio, se stai per 3 minuti fermo a guardare il soffitto, alla fine dei 3 minuti tu sei invecchiato di 3 minuti: fidati, ne sono successe di cose alle tue cellule.
Quindi:
1) determina che cosa intendi precisamente per "nessuna attività";
2) di conseguenza, determina quali sono gli eventi che, quando succedono, hanno il potenziale di essere "gli ultimi" che succedono;
3) a partire da ogni evento che potrebbe essere "l'ultimo", fai partire un timer;
4) resetta il timer (ovvero, fallo ripartire da zero) ogni volta che succede un nuovo evento di questo tipo;
5) se il timer arriva a 3 minuti, mostra la schermata di blocco.

E' da anni che non guardo più pyGTK (ma esiste ancora?...) ma sono sicuro che ha tutti gli strumenti (eventi, timer) per fare quello che vuoi.

8
Base / Re:[Win/py3] File aperti da diversi programmi
« il: Febbraio 08, 2019, 10:02 »
Mah, non sono sicuro di quali problemi di concorrenza dovresti avere. Se "il software di terze parti" apre il file lockandolo, al massimo hai IOError quando cerchi di copiarlo, e non ti resta che intercettare l'eccezione e provare più tardi... ma questo è by design. Se nessuno locka il file, meglio ancora: copia il file e vivi felice, il massimo che ti può succedere è che stai copiando una versione non aggiornata ma questo può succedere in ogni caso...

(uhm... ma non avevo già discusso con qualcuno una roba del genere.... Mah. Non sarà questo il caso, ma non è la prima volta... Certe volte ho la sensazione che periodicamente le stesse persone tornino alla carica con la stessa domanda sperando che nel frattempo me ne sia dimenticato, e magari sperando in una risposta diversa... E il bello è che in effetti me ne dimentico sempre!)

(ri-uhm... detto questo, non so se affiderei a python un'operazione di questo tipo. Il sistema operativo in genere ha delle soluzioni robuste, testate, funzionanti. Io schedulerei un bel backup della cartella a intervalli periodici, e mi dimenticherei del tutto del problema).

9
Non hai capito. Se non conosci l'encoding di un file, non è che python possa conoscerlo al posto tuo. Non è un problema di python. La dua domanda equivale a chiedere se nella libreria standard di python esiste un modulo per leggere il pensiero. Non esiste un modulo per leggere il pensiero nella libreria standard di python.
Aprire un file "in qualche modo" è sempre possibile: open di per sé funziona sempre, ci mancherebbe. E' poi leggerlo che può dare problemi. Poi certo, visto che *adesso* menzioni la possibilità di produrre "caratteri strani", credo che tu ti riferisca alla possibilità di settare il parametro "errors" di open https://docs.python.org/3/library/functions.html#open, cosa che è sempre un rifugio possibile... ma questo non è certamente "indovinare l'encoding". 
Detto questo, a me risulta che chardet sia invece *parecchio* funzionale, anche e soprattutto con file prodotti in ambiente windows. Dopo tutto, se va bene a Mozilla... Ma lo hai *davvero* provato?
Uhm, a proposito: se un file di testo non-utf8 viene prodotto in ambiente windows, è più probabile che qui da noi sia encodato in cp1252, che NON è la stessa cosa di iso-8859-1...

In ogni caso: https://docs.python.org/3.3/howto/unicode.html
e https://pythoninwindows.blogspot.com/2018/08/installare-e-usare-python-su-windows9.html

10
Sì ma al di là di questo non capisco dove risiede concretamente il problema. Csv è un file di testo puro, ed è noto che i file di testo puri non hanno metainformazioni sull'encoding. Se anche ci fosse uno standard che "prescrive" utf8, non ci sarebbe nessun modo per imporlo visto che appunto, un file di testo non ha modo di segnalare l'encoding in cui è scritto.
Quindi, hai in mano lo stesso problema che avresti con qualsiasi altro file di testo. Il fatto che sia un csv è una falsa pista che non c'entra niente.
Il problema è: quando apri un file di testo, O sai l'encoding (e allora sei a posto) OPPURE non lo sai (e allora sei nei pasticci). Se non lo sai, hai due strade: O cerchi di saperlo (informandoti bene presso il provider di quel file), OPPURE tiri a indovinare, per esempio con chardet https://github.com/chardet/chardet o librerie analoghe.

11
Base / Re:Cosa succede in questo caso con imp.load_source?
« il: Gennaio 16, 2019, 16:40 »
> è piuttosto esplicativo, con quel:
> # cerca files .py in una cartella

Sarà esplicativo per te che sai già che cosa c'è dietro. Ma chi ti legge, come fa a sapere QUALE operazione in concreto stai usando per "cercare files in una cartella"?

> e questo è solo per evitare di dover restartare il programma se faccio una modifica/aggiungo/tolgo files

eh, ma questo invece è proprio quello che dovrai fare in ogni caso, invece... Nel senso: anche lasciando perdere casi estremi (race conditions... boh, non so), resta che quando fai os.listdir su una directory ottieni uno "snapshot" della situazione *in quel momento*. Nell'intervallo che corre tra quel momento e il momento in cui operi effettivamente sui file (per esempio li apri), non hai nessuna garanzia che la situazione non sia già cambiata. In particolare, visto che lo hai menzionato (e io me n'ero dimenticato), il problema più grave non ce l'hai quando viene *aggiunto* un file ma quando ti viene *tolto* da sotto il naso. Anche solo se fai quacosa come

for item in os.listdir('.'):
    with open(item, 'r') as f:
        f.read()

può darti errore: se ci sono molti molti file e sono molto pesanti, se sei abbastanza svelto riesci addirittura a crashare il programma togliendo "a mano" uno degli ultimi file della directory prima che python arrivi a leggerlo...
Tutto questo per dirti, ripeto, che il tuo problema
a) non è tanto preoccuparti di "coincidenze" strane nel momento in cui "riempi la lista con i nomi dei file". Per quello puoi fidarti abbastanza delle primitive del sistema operativo sottostante
b) non è tanto preoccuparti che dopo che hai "riempito la lista" qualcosa possa cambiare nella directory: questo è normale e *sicuramente* potrebbe accadere. Devi rassegnarti a questa possibilità. Al limite puoi fare polling della directory a tempi regolari, se proprio per te è importante.
c) invece devi preoccuparti di "coincidenze" strane nel momento in cui *apri* ciascun file per lavorarci. E' in quel momento che devi essere pronto a intercettare l'eccezione appropriata (il file non esiste più, oppure è aperto in scrittura da un altro processo, etc.).

12
Base / Re:Cosa succede in questo caso con imp.load_source?
« il: Gennaio 14, 2019, 19:30 »
Ma ti rendo conto che hai postato un pezzo di codice con esattamente SEI nomi non definiti? Di quante sfere di cristallo c'è bisogno per divinare quello che stai facendo davvero? Ora, nel caso specifico per fortuna (beh, diciamo...) questo non ha importanza importanza perché il tuo problema non sta comunque nel codice che hai postato, ma nella parte che non hai postato: e origina in ogni caso dal modo in cui questi nuovi file possono essere aggiunti alla directory, al di fuori del tuo codice. In ultima analisi questo dipende dalle primitive del sistema operativo che ci stanno dietro... Per esempio, se dietro c'è un "rename" Posix, allora dovrebbe essere atomico *se* le due path stanno nello stesso filesystem... e anche per Windows dovrebbe valere una cosa analoga... ma qui ci addentriamo in un dedalo di complicazioni mi sa (almeno per me che di file system ci capisco più o meno come di giardinaggio). In ogni caso, c'è ben poco python che c'entra qui.

Mi viene da dire (ma NON lo dico) che la cosa migliore è che tu faccia un po' di test (magari trasferendo file di qualche decina di giga, così da metterci un po' di tempo) e ti prepari a intercettare l'eccezione (OSError, se non riesci a stringere il campo).
Quello che invece dico è... ma che ti importa, poi? Il problema del tuo codice non nasce al momento di "caricare dinamicamente" nel dizionario, come dici... il problema nasce prima, al momento di determinare che cosa contiene "allFilesFromFolder" (che suppongo sia una lista... ah, avere la sfera di cristallo). Una volta che allFilesFromFolder è stato determinato, si chiude la saracinesca e il resto va da sé. A quel punto, o un file sta dentro allFilesFromFolder, oppure non ci sta. Da quel momento in poi, è ovvio che il contenuto reale della directory potrebbe cambiare. Ma solo una nuova operazione di scansione può dirtelo.
Al limite quindi bisognerebbe capire quale operazione fai per "riempire" allFilesFromFolder (ah, la sfera, la sfera di cristallo). Poniamo caso che sia il risultato di un os.listdir: allora (al limite) devi chiederti che cosa succede se qualcuno aggiunge un file nel bel mezzo di un os.listdir. E la risposta è, boh niente suppongo. Cioè, non credo che os.listdir sia di per sé "atomico" (specie su windows): nel senso, è possibile che tra il momento in cui inizia la scansione e il momento in cui finisce qualcosa cambi. Ma non so quanto possa importare: alla fine, os.listdir fa in tempo a vedere il nuovo file, oppure non fa in tempo. E se non fa in tempo, può non farcela per un decimillesimo di secondo o per una settimana ma l'unica è ripetere os.listdir una seconda volta. E più in generale, se proprio è quello che vuoi, metterti a fare polling della directory a intervalli regolari. In ogni caso, è naturale che, in generale, il contenuto "reale" della directory possa cambiare in seguito.

13
ah, ecco: dirlo subito...
Ma intendi "da mezzanotte all'una" di qua, o GMT? Non so esattamente come funziona mechanize (mai usato), ma potresti provare a impostare manualmente il locale prima di invocare mechanize, ma non credo che poi getTimeZoneOffset sia locale-aware (penso che chieda direttamente al sistema operativo... e non credo che tu voglia cambiare il locale del sistema operativo per questo).
D'altra parte, non saprei... ma non puoi provare a prelevare direttamente l'html della pagina (con request, o al limite anche solo con urllib) senza pretendere di eseguire il javascript, e vedere quello che ottieni?

14
Stai sbattendo la testa da giorni sui fusi orari? Quel calendario usa il fuso di Londra (GMT). Poi a un certo punto quando lo carichi sul browser, javascript chiama getTimeZoneOffset() https://www.w3schools.com/jsref/jsref_gettimezoneoffset.asp, aggiunge l'offset e tu vedi l'ora italiana. I tuoi tool, invece, non eseguono quella funzione, o non riescono a leggere l'offset, va a sapere. Che ti importa? Puoi comunque farlo tu a mano dopo, direi.

15
Base / Re:esercizio a casa
« il: Gennaio 08, 2019, 21:43 »
Puoi almeno cominciare a scrivere una funzione che riconosca la prima coppia di numeri utili, la "fonda" e restituisca la lista rimpicciolita. Di qui, vedi dove puoi andare.
Il problema di fondo è che se ti danno questo esercizio (di complessità medio-facile) e tu non hai neanche la più pallida idea di come impostare il ragionamento, vuol dire
- o che il corso che segui è fatto molto molto molto male
- o che tu hai perso davvero troppe lezioni.

Pagine: [1] 2 3 ... 218