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 ... 226
1
Base / Re:carattere $
« il: Aprile 01, 2020, 10:17 »
Caspita, non lasciamo scappare via questo thread senza fare almeno un brindisi.

L'OP sta seguendo un *tutorial*, e a quanto sembra che questo tutorial gli sta insegnando a FARE LA COSA GIUSTA, ovvero usare Python dalla shell del sistema operativo! Evviva, non posso crederci. Vuoi far girare lo script "aritmetica.py"? Bene, apri una dannata shell e fallo girare nel modo che Guido van Rossum ha inteso che dovessero girare gli script quando ha creato Python... e con lui, tutti quelli che hanno creato dozzine e dozzine di altri linguaggi di programmazione, dagli anni '70 in avanti.
Niente scempiaggini del tipo "premi F5 in Idle". Niente stupidaggini del tipo "fai doppio clic sullo script". Niente (ok, qui censura) del tipo, visto anche di recente su questi schermi, "adesso ti insegno Python... per prima cosa installati Visual Studio Code".

Proprio così... è possibile (incrociamo le dita) che l'OP si sia imbattuto nel Sacro Graal del Tutorial Che Fa Le Cose Per Bene.
Complimenti a lui per la sua fortuna o il suo impeccabile buon gusto. Penso che l'OP ci farebbe un favore a linkare questo tutorial.

(poi certo, c'è il fatto che l'OP a quanto pare non sa usare la shell, neanche un minimo. Questo esula dai compiti del tutorial: tuttavia sarebbe bene che il tutorial almeno avvertisse che per programmare in Python occorre anche una minima competenza sulla shell)

2
wxPython / Re:Libro italiano su wxPython disponibile!
« il: Marzo 26, 2020, 19:29 »
Ancora quattro capitoli nuovi, appena pubblicati!
Questa volta, gli eventi del mouse e della tastiera (il focus!), il sistema degli aiuti in linea (tooltip etc.) e le tecniche per sincronizzare lo stato della GUI.

Sul mio blog, un annuncio più completo, con tanto di retroscena...
https://pythoninwindows.blogspot.com/2020/03/quattro-nuovi-capitoli-del-libro.html

Il link al libro è sempre https://leanpub.com/capirewxpython
Il prezzo è sempre il solito (e come sempre per chi ha già comprato il libro, l'aggiornamento è gratis). Compratelo... anche se non usate wxPython il prezzo è talmente basso (per 400 e passa pagine!) che come si fa a dire di no... ehm.

3
Python-it.org cafè / Re:ORM : quando sono utili?
« il: Marzo 19, 2020, 14:43 »
Mah per prima cosa un orm non serve a "poter cambiare database senza cambiare il codice". Nessuno davvero vuole fare una cosa del genere: quando ti tocca davvero farlo in produzione, son dolori non da poco. E comunque, per quanto un orm possa astrarre, le differenze specifiche tra i diversi database sono sempre lì, e se vedi ci sono sezioni apposite della documentazione degli orm dedicate appunto a spiegare che cosa si può fare con un database e che cosa si può fare con l'altro.
(e quindi sì, anche gli orm sono "leaking abstractions"... non ti salvano dal peso di dover studiare a fondo il database sottostante https://pythoninwindows.blogspot.com/2020/03/come-imparare-python-senza-studiare.html )

In secondo luogo, beh, non esistono "dilettanti" e "professionisti", esiste codice scritto bene o scritto male. Quindi, se la domanda è se l'orm ti aiuta a scrivere codice migliore, direi che la risposta è sì... forse... nel senso che eviti certi problemi ma non è detto che tu scriva poi buon codice nello stile dell'orm.

A parte questo, se la domanda è "un orm è utile?", bisogna sempre chiedersi "rispetto a cosa"... Cioè, se non usassi un orm ficcheresti query sql direttamente nel codice? Allora sì, un orm è totalmente assolutamente utile. Ma del resto, se appena ti poni il problema di separare il codice di gestione del database dal codice della tua applicazione, in pratica è probabile che tu stia già inventando un piccolo orm casareccio... e allora, perché non usare direttamente un orm e farla finita, no?

Un'altra cosa terra-terra, è che un orm probabilmente ti costringe a pensare alla gestione del database in termini più corretti: capire che cosa è una connessione, che cosa è una transazione,... problemi di sicurezza... problemi di efficienza... etc. E' probabile che un principiante, studiando bene la documentazione dell'orm, finisca per imparare parecchio anche di sql.

Poi non è che un orm sia la bacchetta magica che risolve i problemi del mondo, eh. A livello teorico esiste un concetto che si chiama "object/relational impedance mismatch" (googla!) che in pratica dice che ci sono delle irriducibili difficoltà a mappare una "tabella" di database con un "oggetto" OOP... e sicuramente tutti gli orm danzano intorno a questo problema, ciascuno a suo modo. Ma onestamente, direi che prima di arrivare a quel punto, di strada se ne può fare parecchia.

Del resto non è che uno sia proprio obbligato a usare un orm. Sqlalchemy, per esempio, ha un orm ma ha anche tutta una libreria DAO estremamente ben fatta.

4
La mia risposta a questa domanda: https://pythoninwindows.blogspot.com/2020/03/come-imparare-python-senza-studiare.html

Era da un po' che volevo scrivere qualcosa del genere... prende una ventina di minuti di lettura, ma credo che ne valga la pena.
D'ora in poi lo userò come risposta standard in un certo numero di casi...

5
Base / Re:Import relativi
« il: Marzo 17, 2020, 12:54 »
@Nunzio
Sì certo, con gli import assoluti si possono fare delle cose. L'OP però chiedeva degli import relativi...


Allora...
Oddio, i relative imports... tutte le volte sono una pena.

Allora, la cosa migliore sarebbe leggere con attenzione questa risposta: https://stackoverflow.com/a/14132912 è lunga e complicata ma vale la pena.
Ciò che dico qui sotto è parziale e si riferisce comunque ai concetti spiegati lì.

Per prima cosa, dal fatto che chiami il modulo "main", suppongo che tu lo stia *eseguendo*... E allora la prima regola è: non puoi fare import relativi in un modulo che *esegui*, ma solo in un modulo che, a sua volta, viene *importato*. La ragione è che se il modulo è eseguito, allora il suo nome cambia in __main__ e le informazioni relative alla sua collocazione nel package vanno perdute, e quindi anche gli import relativi che dovesse contenere, saltano senza pietà.

Tolta questa prima cosa banale, la seconda regola è: non puoi fare import relativi da package "fratelli", se a sua volta il "main" (ovvero il modulo che *esegui*) è "fratello" di quei package. Ovvero, se tu hai questa struttura:

base/foo/foo.py
base/bar/bar.py
base/main.py   -> questo è il modulo che esegui

allora non puoi fare un import relativo da bar.py a foo.py o viceversa.
Ovvero, per esempio, non puoi scrivere dentro a bar.py qualcosa come "from ..foo.foo import something" perché il salto all'indietro ti fa già uscire dal package top-level, dal momento che il modulo che esegui è solo "fratello" di foo e bar.

Se però il modulo che esegui, invece di essere fratello, è "genitore" dei due package fratelli, allora tutto funziona, perché quando salti all'indietro non esci dal package top-level.
Ti faccio un esempio di import relativo tra package "fratelli" che funziona: il motivo lo puoi capire precisamente solo se leggi con cura la risposta che ti ho linkato.

=== struttura dei file ====
base/src/foo/foo.py
base/src/bar/bar.py
base/main.py
=== contenuto dei file ===

# file bar.py
def getname():
    print('il nome di bar/bar.py:', __name__)

def bar_funct():
    print('sono bar_funct in bar/bar.py')
# -------------------------------------------
# file foo.py
from ..bar.bar import bar_funct  # import relativo tra package fratelli

def getname():
    print('il nome di foo/foo.py:', __name__)

def foo_funct():
    print('sono foo_funct in foo/foo.py')
    print('adesso eseguo bar_funct:')
    bar_funct()
# --------------------------------------------
# file main.py
from src.foo.foo import getname as fooname
from src.bar.bar import getname as barname

fooname()
barname()

from src.foo.foo import foo_funct

foo_funct()

Le due funzioni "getname" che ti restituiscono il nome del modulo come lo intende Python, ti servono sempre in relazione alla risposta che ti ho linkato, e che devi leggere (devi proprio, sorry).
Ora, se tu invece provi a fare la stessa cosa ma eliminando il "livello" del package "src", ovvero torni alla tua struttura iniziale:

base/foo/foo.py
base/bar/bar.py
base/main.py
=== contenuto dei file ===

# file bar.py  come prima
# -------------------------------------------
# file foo.py  come prima
# --------------------------------------------
# file main.py
from foo.foo import getname as fooname
from bar.bar import getname as barname

fooname()
barname()

from foo.foo import foo_funct

foo_funct()

vedi che adesso l'import relativo non funziona. E vedi però anche come cambiano i nomi di foo.py e bar.py


Detto tutto questo, attenzione però anche a una cosa:
primo, gli import relativi sono un antipattern e andrebbero evitati.
Secondo, in ogni caso il meccanismo di "import" non serve a caricare codice da posizioni arbitrarie nel file system. Non è come quando dalla shell fai "cd ../../foo/../bar" e ti sposti da un punto a qualsiasi altro punto. Gli import devono pur sempre rimanere nell'ambito di uno stesso package (e subpackage) così come il package viene inteso da python in base alla locazione del modulo "main" che stai eseguendo (sempre, vedi la risposta che ti ho linkato).
Ora, nel caso di package "fratelli" puoi pur sempre usare gli import assoluti. Anche nel secondo scenario (quello che non funziona con gli import relativi), se invece di fare from ..bar.bar import bar_funct tu fai from bar.bar import bar_funct, quello funziona con gli import assoluti (perché la path completa del package dipende dalla locazione del "main" eseguito).
Ma in generale, se vuoi importare qualcosa che sta arbitrariamente fuori dal package "top-level", non puoi farlo neanche con gli import assoluti. In quel caso, è un problema più ampio di organizzazione del tuo progetto. Puoi usare PYTHONPATH (ma è un hack che funziona solo sulla tua macchina, ovviamente) oppure puoi installare con pip (ma ha senso solo con delle librerie che a loro volta potrebbero essere distribuite a parte su PyPI, non certo con un modulo "utils" qualunque). Ma comunque devi porti il problema a livello più ampio di organizzazione del progetto.


Edit: ho rinominato in "src" il package che nella prima versione di questo post avevo chiamato "all"... un po' perché "all" è un nome riservato, e mi sono vergognato... Ma soprattutto perché tutto questo ha anche a che vedere con la discussione di usare "src" per strutturare i progetti... cosa che per alcune ragioni un po' complesse è in realtà consigliabile e che adesso sta andando più di moda che in passato. Per capirne qualcosa, https://hynek.me/articles/testing-packaging/ ma non è una lettura facilissima.

6
Base / Re:Aiutino su programma python
« il: Marzo 16, 2020, 16:31 »
Beh, sì... è una funzione e se qualcuno da qualche parte non la chiama, lei non è che fa qualcosa di sua iniziativa. E quello è un ciclo infinito, quindi... come dicevo sopra.

In linea di massima non puoi pretendere di capire / saper fare un programma Python senza avere un senso dei più comuni controlli di flusso, di come funzionano le funzioni, di che cosa è una variabile... eccetera. Purtroppo non c'è niente da fare, contrariamente a quanto sicuramente hai sentito in giro, Python è un linguaggio *difficile* e occorre tempo per impararlo prima di poterci lavorare. Attaccare insieme pezzi di codice trovati in giro... non funziona tanto.

Il consiglio è sempre quello: rinunciare a perseguire un obiettivo immediato e prendersi un bel po' di tempo a seguire passo-passo un libro... ma che sia un buon libro, (cioè... ehm... non quello che hai scaricato)... Il Lutz qui è sempre il consiglio che mi sento di dare... Anche perché il materiale in Italiano ovviamente è più scarso.

7
Base / Re:Problema installazione pacchetto
« il: Marzo 16, 2020, 12:06 »
Sigh... quel libro è... terrificante.
Ma ormai suppongo che tu l'abbia comprato, quindi è inutile piangere sul latte versato...

Detto questo, per installare un pacchetto con pip dovresti avere un minimo di dimestichezza con la shell del tuo sistema operativo, la nozione di directory corrente e così via. In generale "trovare un pacchetto" locale vuol dire semplicemente dargli la path (relativa o assoluta) corretta del file. Quindi,
- o prima ti porti della directory in cui c'è il file e poi gli dici "pip install pacchetto",
- o dalla directory in cui ti trovi adesso gli dai la path relativa che lo conduce al pacchetto e quindi fai "pip install path/relativa/al/pacchetto"
- o dalla directory in cui ti trovi gli dai la path assoluta del pacchetto e quindi fai "pip install /path/assoluta/del/pacchetto"

Poi magari il pacchetto non riesce a installartelo ugualmente perché è troppo vecchio o va a sapere, ma almeno te lo trova.

A proposito, se hai l'indirizzo http preciso del pacchetto (e dovresti avercelo, visto che lo hai scaricato), allora puoi anche fare "pip install http://www.blabla.com/path/al/pacchetto" e dovrebbe scaricarlo e (incrociando le dita) installarlo.

(ovviamente tutto questo dovresti farlo da dentro un virtual environment ma... sarà per un'altra volta suppongo)

8
Base / Re:Aiutino su programma python
« il: Marzo 15, 2020, 19:10 »
Mah, per prima cosa per cortesia formatta il codice con l'apposito pulsante "pythoncode", altrimenti non si capisce niente...

In secondo luogo, non capisco come hai fatto a scrivere quel codice se sei "decisamente inesperto"...
in ogni caso, a vederlo così (ripeto, non è formattato quindi non riesco a capire dove dovrebbero essere i rientri) a un certo punto quel codice sembra entrare in un ciclo while True e non ne dovrebbe più uscire... la tua parte "aggiunta" è una funzione, che ovviamente da sola non farà mai niente se non viene eseguita da qualche parte... e suppongo che a questo punto "da qualche parte" dovrebbe essere all'interno del ciclo, perché quando entra lì non esce poi più... Ma non capisco di preciso che cosa ti aspetti...

Uhm. Potrei sbagliare ma non sono sicurissimo, in tutto questo, che tu abbia chiaro il concetto di "definire una funzione" e "eseguire/chiamare una funzione"... e se è così, questo in effetti è un problema.

9
Videogame / Re:errore nell'installazione di pygame
« il: Marzo 13, 2020, 09:58 »
mah... davvero l'installer di pygame fa... questo?  :confused: e così, come una filastrocca non formattata né niente? Cavolo... Comunque non so niente né di mac né di pygame, quindi non azzardo ipotesi... ovviamente al fondo dice che c'è un log... al limite dovresti cercarlo e guardare lì dentro.

10
Base / Re:Errore utilizzo di openpyxl con file .xlsm
« il: Marzo 13, 2020, 09:56 »
mah, in realtà non c'è una Comprensione Superiore Degli Stacktrace che si ottiene solo allenandosi con un maestro jedi in una foresta... basta avere la pazienza di leggere lo stacktrace molto lentamente, dedicandoci del tempo senza distrazioni... certo con il tempo si diventa più allenati e si acquisisce un certo colpo d'occhio, ma... in sostanza è solo questione di non aver fretta.
Dopo di che, se è solo questo l'errore, direi che ti basta cancellare il link guasto, e riprovare ad aprirlo...

Poi, se vogliamo proprio dirla tutta... ammesso che il problema sia questo, allora è sicuramente una svista di openpyxl che andrebbe segnalata... Il problema qui è che l'autore della libreria non ha previsto che in fase di parsing un link potesse essere guasto, e quindi se succede questo la libreria lascia propagare l'eccezione che proviene "dal basso" (ovvero in questo caso da xml.etree) senza fare nulla, e questo in effetti complica la vita...

11
Videogame / Re:errore nell'installazione di pygame
« il: Marzo 11, 2020, 15:57 »
prenditi del tempo a leggere "l'errore chilometrico" e probabilmente riuscirai a farti un'idea di che cosa è andato storto.
Detto questo, sei sei un neofita non iniziare da Pygame.

12
Base / Re:Errore utilizzo di openpyxl con file .xlsm
« il: Marzo 11, 2020, 14:44 »
Eh... vedi che è uno stacktrace diverso da quello di prima? Capisci che non è lo stesso di prima? Puoi confrontare quello di prima e quello di adesso e verificare che in effetti non sono lo stesso? Prima era una cosa, adesso è un'altra cosa? Ci siamo chiariti su questo punto? Non abbiamo ulteriori dubbi su questo?

Bene, adesso che abbiamo uno stacktrace più fresco, e che in effetti corrisponde al codice sorgente dell'ultima versione della libreria, possiamo dire qualcosina in più. A quanto pare, nell'aprire il workbook e parsarlo, prima o poi si imbatte a un link a un workbook esterno... almeno, questo è ciò che dovrebbe fare "workbook/external_link/external.py"... di nuovo, non sto approfondendo molto la cosa, quindi consiglio di non fidarsi ciecamente di quello che dico e verificare...
E, se ho ragione fin qui, a quanto pare nel leggere questo link esterno trova un errore... Che tipo di errore? Non è chiaro perché a questo punto la libreria si appoggia a xml.etree della libreria standard, e lascia propagare l'eccezione che viene su da questa senza cercare di intercettarla o commentarla in qualche modo. Quindi non credo che l'indicazione "line 2, column 246703" voglia davvero dire che tu stai cercando di aprire un foglio excel con 24mila colonne, anche perché non credo che ci potrebbero stare 24mila colonne in un foglio excel. Deve essere un conteggio interno di xml.etree che non ti aiuta molto a identificare la cella che contiene l'errore. Boh?
In ogni caso, cerca di capire se all'interno del file che stai aprendo ci sono dei link a fogli esterni... perché a me sembra che l'errore potrebbe essere qui.

Se non ci sono link a fogli esterni, allora ho torto e non ti resta che andare ulteriormente per tentativi. Per esempio, prova a tenere solo un blocco di dati nel tuo foglio, e aprirlo... prima o poi troverai il blocco di dati che causa problemi, e forse puoi risalire alla causa...

In ogni caso, direi che è definitivamente un problema del tuo file, non della libreria... O più precisamente: se il tuo file non appare corrotto aprendolo in Excel, allora deve avere qualche caratteristica che non è supportata dalla libreria. Se riesci a isolare il problema, puoi segnalarlo agli autori della libreria.

13
Multimedia / Re:Aiuto con optical mark recognition
« il: Marzo 11, 2020, 12:49 »
mah in effetti è un po' un giocattolo... si potrebbe lavorarci sopra ma mi chiedo se ne valga la pena. Prova con qualcos'altro... per esempio a un'occhiata veloce questo https://github.com/GregoryCMiller/omr mi sembra più documentato, e soprattuto dovrebbe essere possibile inserire coordinate per modelli nuovi in un file yaml esterno. Non l'ho provato e visto che è codice vecchio di 6 anni magari avrai qualcosina da aggiornare... ma almeno mi sembra più abbordabile

14
Base / Re:Errore utilizzo di openpyxl con file .xlsm
« il: Marzo 07, 2020, 21:41 »
@nunzio
> Se arrivare al sorgente dei moduli è "molto superficiale" : mammamia!

Guarda, francamente sì. DIco "superficiale" perché non ho controllato veramente che cosa è successo, potrei essermi sbagliato, etc etc. Però in questi casi
1) leggere con un po' di attenzione lo stacktrace
2) andarsi a guardare come funziona il sorgente in corrispondenza dei punti problematici indicati nello stacktrace
è *davvero* il minimo da fare. La documentazione ti aiuta fino a un certo punto...
Una cosa meno superficiale, se vuoi, sarebbe stata clonarsi la repo e fare un git blame su quel modulo per cercare di capire che cosa c'era scritto una volta... solo che onestamente non avevo tanta voglia.


@OP
> riprovato lo script e mi dà sempre errore

ovviamente NON PUO' ESSERE lo stesso errore. Abbi pazienza, ma per programmare ci vuole un po' più di precisione lessicale del "gigi, per me il solito" che usiamo al bar per ordinare un cappuccino. Non può essere lo stesso errore se è cambiato il codice coinvolto. Per definizione. Quello che dovresti/potresti fare è postare di nuovo lo stacktrace preciso per farci capire ADESSO quali parti del codice sono coinvolte nell'errore che ricevi, e (forse, eventualmente, magari) capire dove sta il problema.

Anche se, come Nunzio rileva, a questo punto è probabile che per qualche ragione stia nel tuo file...

15
Tkinter / Re:Gestione multilingua con gettext e StringVar
« il: Marzo 07, 2020, 21:32 »
...e io ti ho detto: leggi i link che ti ho mandato. Anche se ci metti del tempo. Non è questione di "applicare una ricetta", è questione di "capire una architettura".

A questo, aggiungo... quello che stai cercando di fare (cambiare lingua a runtime) non è consueto, e raramente ha senso. Il problema è che devi ridisegnare tutta la gui... nessuno fa questo, in una gui desktop. E' invece frequente, ovviamente, nelle web gui, dove semplicemente tu fai una request e il browser ti ricarica comunque la pagina... è quello che farebbe comunque. Ma una gui desktop non è fatta in linea di principio per questo scenario. Nelle cose che ti ho linkato spiego anche questo, ma un po' di sfuggita. Se ben ricordo ne parlo più diffusamente nel capitolo dedicato nel mio libro, ma quello è per wxPython.

Pagine: [1] 2 3 ... 226