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: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.

2
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.

3
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.

4
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.

5
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).

6
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

7
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.

8
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.).

9
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.

10
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?

11
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.

12
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.

13
wxPython / Re:wx.App.stdioWin ... ma dove si trova?
« il: Gennaio 05, 2019, 18:21 »
Uhm, sì all'incirca è così. PyOnDemandOutputWindow è una classe *scritta in Python puro* (da cui l'iniziale Py...) per le esigenze specifiche di wxPython (nel senso: in wxWidgets le cose stanno diversamente, e questa classe non c'è). Il suo scopo è quello di disegnare un semplice frame per il reindirizzamento degli stream di output. Siccome è scritta in Python, la sua api segue lo stile di Python anche per differenziarsi visivamente dalle "normali" classi wxPython: pertanto i suoi metodi sono tutti minuscoli.
Le "normali" classi wxPython sono dei wrapper intorno alle corrispondenti classi di wxWidgets, generati automaticamente (da SWIG una volta, ora da SIP). Pertanto seguono il code stile di wxWidgets, con i nomi dei metodi in CamelCase.

Detto questo, ho aggiunto un disclaimer generale ai miei appunti, che dovresti leggere:
https://forumpython.it/wxpython/appunti-wxpython-in-italiano-disponibili/msg88298/?topicseen#msg88298

14
wxPython / Re:Appunti wxPython in italiano disponibili
« il: Gennaio 05, 2019, 18:09 »
Arrivati al 2019, è necessario aggiungere un disclaimer bello grosso: questi appunti su wxPython si riferiscono alla "vecchia" versione di wxPython (cosiddetta "classic") che usa ancora Python 2.
Siccome Python 2 a fine anno andrà definitivamente in pensione, e siccome nel frattempo è uscita la nuova versione di wxPython (cosiddetta "Phoenix", a partire da wxPython 4.0.0) che supporta Python 3, siete cordialmente invitati
a) ad aggiornare il vostro stack Python / wxPython
b) a prendere i miei appunti con un pizzico di prudenza.

Per quanto riguarda il punto b: wxPython "Phoenix" è *quasi* uguale a wxPython "classic", e pertanto i miei appunti sono ancora *quasi* sempre validi, se appena aggiornate lo stile quel poco che occorre (per esempio, ci sono tutti i print senza parentesi... ma poco male). Il diavolo sta nei dettagli e nei *quasi*, tuttavia. Ci sono piccole differenze qua e là, e potreste inciamparci dentro. State all'occhio.

In generale, questi appunti continuano a essere la risorsa più accurata disponibile in Italiano... ma certamente andrebbero aggiornati.

E qui c'è una buona notizia e una cattiva notizia.
La buona notizia è che mi sono messo a scrivere una gigantesca (gi-gan-te-sca) guida su wxPython, espandendo parecchio questi appunti, rivedendoli in profondità, e aggiungendo un sacco di capitoli. Ovviamente questa nuova guida si riferisce a wxPython "Phoenix" e a Python 3.
La cattiva notizia è che mi sono interrotto e non credo che andrò avanti. Il problema è che si tratta di un lavoro veramente grande (parliamo di un libro di 600 pagine secondo le stime, di cui circa 200 sono già scritte), per una tecnologia tutto sommato ormai un po' marginale (le gui desktop... nel 2019... via...), insomma non ne vale la pena. Peccato perché wxPython mi piace e continuo a usarlo.
Il problema aggiuntivo è che comunque ho scritto in Italiano... riducendo del 99% il mio potenziale pubblico. Anche qui, peccato perché sicuramente il mio "librone" sarebbe una risorsa eccellente anche per gli standard di ciò che è disponibile in Inglese.

Ora, se qualcuno inciampa in questo post e mi dà qualche suggerimento su una modalità di pubblicazione/presentazione/divulgazione che possa darmi un po' di visibilità, e/o qualche soldino, e/o interessarmi/incuriosirmi in qualche modo... potrei ripensarci.

Il 2019 è ancora lungo... vediamo che cosa porterà.

15
Altri linguaggi / Re:Integrare pesantemente Python e C++
« il: Gennaio 03, 2019, 08:38 »
> se volessi fare qualcosa di crossover senza dover ricompilare
Se volessi, non potresti. Questo è c++. Poi puoi fare cross-compiling, ma comunque anche questo è un aspetto di c++, non di python.

> Volessi, controllare se il parametro passato è una lista o numpy
Veramente il problema sarebbe a rovescio, no? Tanto c++ non accetta né una lista python né un "numpy" (mah), quindi al limite devi avere un meccanismo che converte entrambi, per dire, in un array c++. Ma convertire tipi avanti e indietro tra python e c++ è comunque il lavoro abbastanza standard di SIP, SWIG e le altre librerie sopra citate.

Uhm, non è che la vaghezza del post sia diminuita molto. Forse ti conviene farti un giro sulla documentazione di un po' di questi prodotti (forse inizierei con SIP, se devi integrare librerie o framework c++ già esistenti... ma non so qual è il tuo caso) e farti un'idea delle possibilità.

Pagine: [1] 2 3 ... 218