[Python] R: Help Tkinter

[Attilio Menegon]

[Python] Help Tkinter

 

Ciao a tutti,

Ho definito un pulsante su un contenitore la cui pressione scatena questo:


def pulsante1Premuto(self, evento):
   for i in range (1, 10):
self.listbox1.insert(END, str(i))
time.sleep(1)

Ora mi aspetto che nella mia listbox appaia un numero circa ogni secondo.

Cio non accade, i numeri vengono scritti tutti contemporanelamente dopo
circa 10 secondi.

Quindi mi pare di capire che *prima* finisce il ciclo e *poi* scrive.

Come posso ottenere la scrittura ogni decimo di secondo?

Grazie.
-- 
Riccardo Brazzale
Linux User #299418 Linux Machine #184578

 

 

Ciao,

 

Ho provato ad inserire dopo

Time.sleep(1)

 

self.listbox1.update()

 

e funziona.

 

Il codice diventa:

 

def pulsante1Premuto(self, evento):
   for i in range (1, 10):
self.listbox1.insert(END, str(i))

time.sleep(1)

self.listbox1.update()

 

Buona giornata a tutti.

 

Attilio Menegon

 

 

 

 

 

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] R: Help Tkinter

[Riccardo Brazzale]

Il giorno 19 novembre 2013 09:50, Attilio Menegon <
attilio.mene...@tecnoemmesnc.it> ha scritto:


> self.listbox1.update()


Grazie!!





-- 
Riccardo Brazzale
Linux User #299418 Linux Machine #184578
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Pietro Battiston]

Il giorno lun, 18/11/2013 alle 17.22 +0100, Matteo Vitturi ha scritto:
> [...]
> > 
> > Per capire, mi sono andato a vedere la query che sqlalchemy genera,
> ed è
> > come segue:
> > 
> > "SELECT a.id AS a_id, a.col AS a_col FROM a, arel WHERE ? = arel.id1
> AND
> > a.id = arel.id2", la_mia_id
> > 
> > Provando a chiamare direttamente questa query direttamente con
> sqlite,
> > in effetti ottengo lo stesso effetto che usando l'ORM di slqalchemy.
> > 
> > Ora, le mie conoscenze/ricerche di SQL sono sufficienti per farmi
> capire
> > che questa è una JOIN implicita, e qual'è la sua logica. Però non
> > capisco:
> > 1) dal punto di vista implementativo: com'è possibile che una JOIN
> sia
> > così più lenta di svariate SELECT che fanno (concettualmente, per
> quel
> > che ne posso capire) esattamente lo stesso lavoro?!
> > 2) ammesso che debba essere così, cosa impedisce a sqlalchemy di
> usare
> > le stesse SELECT che uso io, per recuperare esattamente la stessa
> roba?!
> [...]
> > Pietro
> 
> Sqlite accede a AREL cercando id1=la_mia_id: in assenza di indice su
> AREL.id1 effettua una ricerca lineare. Supponiamo pure che questo per
> scorrere tutta la tabella serva un decimo di secondo.
> Per ogni riga ottenuta accede alla tabella A cercando quale "id"
> batta: in assenza di indice su A.id effettua una ricerca lineare, ogni
> volta impiegando un decimo di secondo per scorrere tutta la tabella.
> Ora, con milioni di decimi di secondo si si arriva facilmente a
> qualche giorno di esecuzione...
> 
> Aggiungi due indici.

Grazie! (anche a Simone e Manlio) Sarà ormai charo a tutti che,
parafrasando il Subject, non avevo capito più o meno nulla.

(quello che mi fregava è che gli indici sulle colonne id delle tabelle
principali erano stati creati automagicamente, per cui lì tutto era
"naturalmente efficiente" - ben sotto il costo di una ricerca lineare -
e non capivo perché non lo fosse sulle secondarie)

Pietro

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Manlio Perillo]

On 19/11/2013 10:31, Pietro Battiston wrote:

[...]

Aggiungi due indici.


Grazie! (anche a Simone e Manlio) Sarà ormai charo a tutti che,
parafrasando il Subject, non avevo capito più o meno nulla.

(quello che mi fregava è che gli indici sulle colonne id delle tabelle
principali erano stati creati automagicamente,


Per le colonne dichiarate PRIMARY KEY, il database aggiunge un indice 
automaticamente.  In realtà l'indice viene creato per le colonne 
dichiarate UNIQUE (altrimenti il controllo sarebbe troppo inefficiente), 
ed ovviamente una colonna PRIMARY KEY è unica (personale interpretazione).


Vedi:
http://sqlite.org/lang_createtable.html


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Simone Federici]

Aggiungerei che è buona pratica mettere un indice sulle colonne delle FK.
Se è una OneToOne, è unica e l'indice c'è già, ma se non è unique, allora
bisogna aggiungere un indice, altrimenti fisicamente su disco o in memoria,
a seconda delle dimensioni, il db deve crearsi una struttura dati e mettere
tutto a confronto.

In effetti non ho capito perchè i DB, nessun db che io sappia, mettono un
indice automatico sulle FK.

2013/11/19 Manlio Perillo 

> altrimenti il controllo sarebbe troppo inefficiente


Ma di questo magari @Manilo, sono sicuro riuscità a illuminarmi.

ciao
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Pietro Battiston]

Il giorno dom, 17/11/2013 alle 20.40 +0100, Manlio Perillo ha scritto:
> On 16/11/2013 18:57, Pietro Battiston wrote:
> > [...]
> >
> > Ora, io di norma non tocco un database se non tramite sqlalchemy. Fingo
> > che sia perché mi piace scrivere codice portabile/elegante - la verità è
> > che fino a ieri non avevo mai scritto una query SQL.
> >
> 
> Male, anzi malissimo.
> Invece di imparare ad usare una libreria, specialmente una cosa 
> complessa come l'ORM di SQLAlchemy, ti consiglio di imparare l'SQL.
> 

Pensa che uso pure urllib/urllib2/Request senza conoscere lo stack
TCP/IP...

A parte gli scherzi: non dico che l'ORM di SQLAlchemy sia _semplice_, ma
non l'ho mai trovato tanto più complesso di quanto lo fossero le mie
esigenze.

> Un ultimo consiglio è di non usare l'ORM a meno di non aver bisogno 
> veramente delle sue funzionalità (ossia in quei casi in cui dovresti 
> reimplementarti le query non banali a mano); non è questo il tuo caso, 
> quindi usa sqlalchemy.schema e sqlalchemy.sql, che è comunque conveniente.
> 

OK, OK, uso l'ORM perché non conosco SQL... ma _anche_ perché mi fa
risparmiare parecchio codice, e perché preferisco passare istanze che
id/righe... non è una motivazione molto pythonica?!

Per quello ne ho capito io, _la_ funzionalità dell'ORM è mappare righe
in oggetti... e non riesco a pensare ad un caso in cui _non_ ne abbia
"bisogno veramente".

Pietro

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Problema con EASYECLIPSE inserimento di "\r" a fine stringa!

[Gollum1]

Il 19 novembre 2013 08:55, Massimo Ceraldi  ha scritto:
> Salve,
> qualcuno di voi usa EasyEclipse per digitare codice?
> Ho un problema, quando al codice chiedo l'inserimento di un carattere
> tramite str = raw_input.("Y or N"), nel momento in cui inserisco il
> carattere, e do invio, mi accorgo che l'editor inserisce anche il valore di
> a-capo (\r se non ricordo male!). Ciò mi crea problemi nel momento in cui
> devo confrontare il valore della variabile con la risposta scelta. in parole
> povere in un costrutto : "if str="Y", lo valuta 'FALSE' perchè str è uguale
> a "Y\r".  Con l'ILDE di default ciò non succede. Dato che EasyEclipse mi
> aiuta nel autocompletamento del codice, esiste un modo per evitare la
> memorizzazione di \r?

http://bit.ly/185z89d

leggi bene tutto il post, più sotto trovi anche quello che serve a te.

-- 
Gollum1
Tesoro, dov'é il mio teoro...
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Digest di Python, Volume 93, Numero 26

[Gollum1]

Il 19 novembre 2013 08:55, Massimo Ceraldi  ha scritto:
> Salve,
> qualcuno di voi usa EasyEclipse per digitare codice?
> Ho un problema, quando al codice chiedo l'inserimento di un carattere
> tramite str = raw_input.("Y or N"), nel momento in cui inserisco il
> carattere, e do invio, mi accorgo che l'editor inserisce anche il valore di
> a-capo (\r se non ricordo male!). Ciò mi crea problemi nel momento in cui
> devo confrontare il valore della variabile con la risposta scelta. in parole
> povere in un costrutto : "if str="Y", lo valuta 'FALSE' perchè str è uguale
> a "Y\r".  Con l'ILDE di default ciò non succede. Dato che EasyEclipse mi
> aiuta nel autocompletamento del codice, esiste un modo per evitare la
> memorizzazione di \r?
>
>
>
> Il giorno 13 novembre 2013 12:00,  ha
> scritto:

[...]


NOTA BENE:

>> Se rispondi a questo messaggio, per favore edita la linea dell'oggetto
>> in modo che sia più utile di un semplice "Re: Contenuti del digest
>> della lista Python..."

[...]

>> --
>>
>> Message: 1
>> Date: Tue, 12 Nov 2013 19:15:23 +0100
>> From: Daniele Palmese 
>> To: Discussioni generali sul linguaggio Python
>> 
>> Subject: [Python] [OT] Documentazione online
>> Message-ID:

[...]

>>
>> --
>>
>> Message: 2
>> Date: Tue, 12 Nov 2013 22:09:01 +0100
>> From: Daniele Zambelli 
>> To: Discussioni generali sul linguaggio Python
>> 
>> Subject: Re: [Python] Richiesta su IDLE
>> Message-ID:

[...]

>> --
>>
>> ___
>> Python mailing list
>> Python@lists.python.it
>> http://lists.python.it/mailman/listinfo/python
>>
>>
>> Fine di Digest di Python, Volume 93, Numero 26
>> **
>
>
>
>
> --
> Massimo Ceraldi

Ma sono solo io che non riesco a capire le risposte ai messaggi nel
formato digest? o chi scrive dovrebbe avere un po' più l'accortezza di
eliminare quello che non serve, ed eventualmente avviare un nuovo
thread e non rispondere ad un'altro che non c'entra nulla...

quoting, questo sconosciuto...

Byez
-- 
Gollum1
Tesoro, dov'é il mio teoro...
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Dario Bertini]

2013/11/19 Pietro Battiston :
> OK, OK, uso l'ORM perché non conosco SQL... ma _anche_ perché mi fa
> risparmiare parecchio codice, e perché preferisco passare istanze che
> id/righe... non è una motivazione molto pythonica?!
>
> Per quello ne ho capito io, _la_ funzionalità dell'ORM è mappare righe
> in oggetti... e non riesco a pensare ad un caso in cui _non_ ne abbia
> "bisogno veramente".

Mi sembra che Manlio parlasse di sqlalchemy core:
http://docs.sqlalchemy.org/en/rel_0_9/core/tutorial.html

forse ti ho frainteso, ma sqlalchemy è molto espressivo anche senza l'ORM
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Manlio Perillo]

On 19/11/2013 11:01, Pietro Battiston wrote:

[...]
A parte gli scherzi: non dico che l'ORM di SQLAlchemy sia _semplice_, ma
non l'ho mai trovato tanto più complesso di quanto lo fossero le mie
esigenze.


Un ultimo consiglio è di non usare l'ORM a meno di non aver bisogno
veramente delle sue funzionalità (ossia in quei casi in cui dovresti
reimplementarti le query non banali a mano); non è questo il tuo caso,
quindi usa sqlalchemy.schema e sqlalchemy.sql, che è comunque conveniente.



OK, OK, uso l'ORM perché non conosco SQL... ma _anche_ perché mi fa
risparmiare parecchio codice, e perché preferisco passare istanze che
id/righe... non è una motivazione molto pythonica?!



Che intendi?


Per quello ne ho capito io, _la_ funzionalità dell'ORM è mappare righe
in oggetti... e non riesco a pensare ad un caso in cui _non_ ne abbia
"bisogno veramente".



Non hai bisogno di mappare tuple (nel senso usato in algebra 
relazionale) in oggetti.
L'oggetto che SQLAlchemy ti restituisce dopo una query è perfettamente 
usabile:


r = sql.select([my_table], where=[...]).fetchall()
for row in r:
  for col in row:
print col

oppure:
for row in r:
   print row['id'], row['rel']



Con l'ORM hai il vantaggio che ti "aggrega" le tuple delle tabelle 
"collegate", a seconda del tipo di relazione usata.  Nell'esempio fatto 
prima row['rel'] sarà l'id della colonna collegata se usi sqlalchemy 
core; con l'ORM sarà un dict-like contenente tutti i dati, oppure una 
sequenza di dict-like nel caso di relazioni uno a molti.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Digest di Python, Volume 93, Numero 26

[enrico franchi]

2013/11/19 Gollum1 

> Ma sono solo io che non riesco a capire le risposte ai messaggi nel
> formato digest? o chi scrive dovrebbe avere un po' più l'accortezza di
> eliminare quello che non serve, ed eventualmente avviare un nuovo
> thread e non rispondere ad un'altro che non c'entra nulla...
>

Molte persone badano più alla loro comodità che a quella dell'intera lista.
In più la gente non legge *nulla*.

Io personalmente uso un altro sistema: quando vedo queste cose,
semplicemente
*non* rispondo alla persona. Semplice: se la persona non ha tempo per
agevolarmi
nell'aiutare, io non ho tempo per aiutare.

-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Incuria, indifferenza, mancanza di rispetto (era: Re: Digest di Python, Volume 93, Numero 26)

[Nicola Larosa]

enrico franchi wrote:
> Molte persone badano più alla loro comodità che a quella dell'intera
> lista.

Vero un po' dappertutto, ahimè.


> In più la gente non legge *nulla*.

A volte si ha quest'impressione. O perlomeno non tutto. :-)


> Io personalmente uso un altro sistema: quando vedo queste cose,
> semplicemente *non* rispondo alla persona. Semplice: se la persona
> non ha tempo per agevolarmi nell'aiutare, io non ho tempo per
> aiutare.

È un forte disincentivo, sì. Hacker avvisato...

-- 
Nicola Larosa - http://www.tekNico.net/

The average cremation of a body with [dental mercury] amalgam emits
as much mercury as is contained in 156 compact fluorescent lamps.
 - http://en.wikipedia.org/wiki/Dental_amalgam_controversy#Cremation
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Incuria, indifferenza, mancanza di rispetto (era: Re: Digest di Python, Volume 93, Numero 26)

[Marco Beri]

> enrico franchi wrote:
> > Io personalmente uso un altro sistema: quando vedo queste cose,
> > semplicemente *non* rispondo alla persona. Semplice: se la persona
> > non ha tempo per agevolarmi nell'aiutare, io non ho tempo per
> > aiutare.

2013/11/19 Nicola Larosa 
> È un forte disincentivo, sì. Hacker avvisato...

È quello che pensavo di fare, ma alla fine penso che non sia una buona idea.

Ho quindi deciso in questo senso: la prima volta rispondo spiegando cosa si
aspetta la lista (magari senza rispondere al problema e chiedendo di
rimandare la mail in maniera corretta).
Al secondo errore ignoro del tutto la mail.

Credo che in questo modo si possa insegnare a chi vuole imparare,
continuando a non perdere tempo con i clue-less.

Io, per esempio, vorrei essere trattato così in un ambiente nuovo che non
conosco.

Ciao.
Marco.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Incuria, indifferenza, mancanza di rispetto (era: Re: Digest di Python, Volume 93, Numero 26)

[Nicola Larosa]

Marco Beri wrote:
> Ho quindi deciso in questo senso: la prima volta rispondo spiegando
> cosa si aspetta la lista (magari senza rispondere al problema e
> chiedendo di rimandare la mail in maniera corretta).
> Al secondo errore ignoro del tutto la mail.

Mi sembra un ottimo approccio.


> Credo che in questo modo si possa insegnare a chi vuole imparare, 
> continuando a non perdere tempo con i clueless.
> 
> Io, per esempio, vorrei essere trattato così in un ambiente nuovo
> che non conosco.

Anch'io. E se fossi da solo a rispondere userei il tuo sistema anch'io.

Ma per fortuna ci sei tu che ci pensi, e posso risparmiarmi la fatica. ;-)

-- 
Nicola Larosa - http://www.tekNico.net/

Realizing I was polyamorous - that I had no choice to be anything
but polyamorous - and beginning to actually live authentically to
who I am was like opening up the curtains and letting all this
sunlight in and seeing things clearly for the first time.
 - Angi Becker Stevens, April 2013
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Incuria, indifferenza, mancanza di rispetto (era: Re: Digest di Python, Volume 93, Numero 26)

[Simone Federici]

2013/11/19 Nicola Larosa 

> Ma per fortuna ci sei tu che ci pensi, e posso risparmiarmi la fatica. ;-)


[Lapsus]
grazie di esistere :-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Pietro Battiston]

Il giorno mar, 19/11/2013 alle 16.10 +0100, Manlio Perillo ha scritto:
> On 19/11/2013 11:01, Pietro Battiston wrote:
> > [...]
> > A parte gli scherzi: non dico che l'ORM di SQLAlchemy sia _semplice_, ma
> > non l'ho mai trovato tanto più complesso di quanto lo fossero le mie
> > esigenze.
> >
> >> Un ultimo consiglio è di non usare l'ORM a meno di non aver bisogno
> >> veramente delle sue funzionalità (ossia in quei casi in cui dovresti
> >> reimplementarti le query non banali a mano); non è questo il tuo caso,
> >> quindi usa sqlalchemy.schema e sqlalchemy.sql, che è comunque conveniente.
> >>
> >
> > OK, OK, uso l'ORM perché non conosco SQL... ma _anche_ perché mi fa
> > risparmiare parecchio codice, e perché preferisco passare istanze che
> > id/righe... non è una motivazione molto pythonica?!
> >
> 
> Che intendi?
> 
> > Per quello ne ho capito io, _la_ funzionalità dell'ORM è mappare righe
> > in oggetti... e non riesco a pensare ad un caso in cui _non_ ne abbia
> > "bisogno veramente".
> >
> 
> Non hai bisogno di mappare tuple (nel senso usato in algebra 
> relazionale) in oggetti.
> L'oggetto che SQLAlchemy ti restituisce dopo una query è perfettamente 
> usabile:
> 
> r = sql.select([my_table], where=[...]).fetchall()
> for row in r:
>for col in row:
>  print col
> 
> oppure:
> for row in r:
> print row['id'], row['rel']


Sì, questo mi è chiaro, ma a me piace più un

print mio_ogg.id, mio_ogg.rel

... a te no?! Perché se sto parlando di utenti e loro informazioni, di
città e loro posizioni, e più in generale di oggetti e loro proprietà,
dovrei scrivere di righe e loro elementi?!

Posso concepire (anche se francamente non ne ho esperienza) la presenza
di tabelle puramente accessorie, che non si mappino a nessun oggetto che
nella mia organizzazione mentale/del codice abbia senso considerare come
tale, e contemporaneamente non siano semplicemente secondary table di
relazioni. In quel caso - sparo - probabilmente sarei portato ad
utilizzare SQLAlchemy core _a fianco_ dell'ORM...

> 
> Con l'ORM hai il vantaggio che ti "aggrega" le tuple delle tabelle 
> "collegate", a seconda del tipo di relazione usata.  Nell'esempio fatto 
> prima row['rel'] sarà l'id della colonna collegata se usi sqlalchemy 
> core; con l'ORM sarà un dict-like contenente tutti i dati, oppure una 
> sequenza di dict-like nel caso di relazioni uno a molti.


Appunto... e anche nei casi in cui (poniamo) non ho tabelle collegate,
con l'ORM la classe me la definisco io, posso aggiungerle dei metodi che
mi servono, e farlo mano a mano che ne ho bisogno, posso definirla come
subclass di qualcos'altro, posso tenere distinti più facilmente i
refactoring che eventualmente dopo un po' io volessi fare al codice che
lavora sugli oggetti e quelli che voglio fare alla struttura del
database (magari tutto ciò lo posso fare in qualche modo anche senza
l'ORM, ma l'ORM mi sembra lo strumento naturale, no?)...

... poi ad un livello più di principio, per me l'ORM è ciò che permette
di usare un database ragionando ad oggetti, e la cosa, a meno di
controindicazioni che ancora mi sfuggono, mi piace.

ciao

Pietro

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Nicola Larosa]

Pietro Battiston wrote:
> ... poi ad un livello più di principio, per me l'ORM è ciò che
> permette di usare un database ragionando ad oggetti, e la cosa,
> a meno di controindicazioni che ancora mi sfuggono, mi piace.

No, va bene, se ti piacciono il Vietnam e gli antipattern. ;-)

Object-Relational Mapping is the Vietnam of Computer Science


ORM is an anti-pattern


-- 
Nicola Larosa - http://www.tekNico.net/

Realizing I was polyamorous - that I had no choice to be anything
but polyamorous - and beginning to actually live authentically to
who I am was like opening up the curtains and letting all this
sunlight in and seeing things clearly for the first time.
 - Angi Becker Stevens, April 2013
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Marco Mariani]

letture un po' più lunghe/impegnative, pur senza essere talebani: the art
of sql; refactoring sql applications; sql for smarties 4ed e l'intero
manuale di postgres.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Marco Beri]

On Tue, Nov 19, 2013 at 5:37 PM, Nicola Larosa  wrote:

> Pietro Battiston wrote:
> > ... poi ad un livello più di principio, per me l'ORM è ciò che
> > permette di usare un database ragionando ad oggetti, e la cosa,
> > a meno di controindicazioni che ancora mi sfuggono, mi piace.
>
> No, va bene, se ti piacciono il Vietnam e gli antipattern. ;-)
>
> Object-Relational Mapping is the Vietnam of Computer Science
> <
> http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html
> >
>
> ORM is an anti-pattern
> 
>

Questa è una di quelle mail che merita di essere forwardata.

Grazie.

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Marco Mariani]

ah, e "sql antipatterns", non ricordo l'editore, certamente il libro più
accessibile e con il quale concordo al 95%. p. s. uso sqlalchemy dalla v0.4
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Manlio Perillo]

On 19/11/2013 17:30, Pietro Battiston wrote:

[...]

oppure:
for row in r:
 print row['id'], row['rel']



Sì, questo mi è chiaro, ma a me piace più un

 print mio_ogg.id, mio_ogg.rel



La differenza tra

   print row['id'], row['rel']

è solo di "facciata", specialmente se tieni conto che, in realtà, quello 
che tu hai scritto è equivalente, in Python, a:


   print mio_ogg.__dict__['id'], mio_ogg.__dict__['rel']


... a te no?! Perché se sto parlando di utenti e loro informazioni, di
città e loro posizioni, e più in generale di oggetti e loro proprietà,
dovrei scrivere di righe e loro elementi?!



Perchè è quello che realmente sono, visto che sono memorizzati in un 
database relazionale.


E non si parla di righe e loro elementi, ma semplicemente di righe 
(anche se il termine corretto sarebbe tupla).

Anche con l'ORM ti restituisce una lista di oggetti, no?


[...]
Appunto... e anche nei casi in cui (poniamo) non ho tabelle collegate,
con l'ORM la classe me la definisco io,


Perchè, la tabella SQL no?


posso aggiungerle dei metodi che
mi servono,


Puoi anche definire funzioni libere, che operano sulla tuple (perchè 
tanto in Python i metodi sono funzioni libere, alla fine).



e farlo mano a mano che ne ho bisogno, posso definirla come
subclass di qualcos'altro,


L'ORM offre alcuni pattern complessi per diverse situazioni.
Però, come ti ha detto Nicola, non è tutto "rose e fiori".


posso tenere distinti più facilmente i
refactoring che eventualmente dopo un po' io volessi fare al codice che
lavora sugli oggetti e quelli che voglio fare alla struttura del
database (magari tutto ciò lo posso fare in qualche modo anche senza
l'ORM, ma l'ORM mi sembra lo strumento naturale, no?)...



Se devi fare refactoring, ci sono metodi ben noti a livello di SQL.


... poi ad un livello più di principio, per me l'ORM è ciò che permette
di usare un database ragionando ad oggetti, e la cosa, a meno di
controindicazioni che ancora mi sfuggono, mi piace.



E' attrattivo certamente.
Ma non bisogna abusarne; io ti ho avvertito poi sei libero di fare come 
voi (ma il consiglio di imparare prima SQL resta, altrimenti se qualcosa 
non funziona/è inefficiente avrai grosse difficoltà).



Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Manlio Perillo]

On 19/11/2013 17:37, Nicola Larosa wrote:

Pietro Battiston wrote:

... poi ad un livello più di principio, per me l'ORM è ciò che
permette di usare un database ragionando ad oggetti, e la cosa,
a meno di controindicazioni che ancora mi sfuggono, mi piace.


No, va bene, se ti piacciono il Vietnam e gli antipattern. ;-)

Object-Relational Mapping is the Vietnam of Computer Science


ORM is an anti-pattern




C'è da aggiungere però che SQLAlchemy fa diverse cose nel modo giusto, 
ad esempio separando la mappatura dallo schema delle tabelle.


Però ho notato che ultimamente sta virando sempre più verso ActiveRecord 
privilegiando il mapping automatico; almeno nel tutorial comincia con il 
mapping dichiarativo.



Ciao   Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Digest di Python, Volume 93, Numero 36

[max050969]

ge: 2
>> Date: Tue, 12 Nov 2013 22:09:01 +0100
>> From: Daniele Zambelli 
>> To: Discussioni generali sul linguaggio Python
>> 
>> Subject: Re: [Python] Richiesta su IDLE
>> Message-ID:

[...]

>> --
>>
>> ___
>> Python mailing list
>> Python@lists.python.it
>> http://lists.python.it/mailman/listinfo/python
>>
>>
>> Fine di Digest di Python, Volume 93, Numero 26
>> **
>
>
>
>
> --
> Massimo Ceraldi

Ma sono solo io che non riesco a capire le risposte ai messaggi nel
formato digest? o chi scrive dovrebbe avere un po' più l'accortezza di
eliminare quello che non serve, ed eventualmente avviare un nuovo
thread e non rispondere ad un'altro che non c'entra nulla...

quoting, questo sconosciuto...

Byez
-- 
Gollum1
Tesoro, dov'é il mio teoro...


--

Message: 3
Date: Tue, 19 Nov 2013 15:58:12 +0100
From: Dario Bertini 
To: Discussioni generali sul linguaggio Python
 
Subject: Re: [Python] O non capisco sqlite, o non capisco sqlalchemy,
 o entrambi
Message-ID:
 
Content-Type: text/plain; charset=UTF-8

2013/11/19 Pietro Battiston :
> OK, OK, uso l'ORM perché non conosco SQL... ma _anche_ perché mi fa
> risparmiare parecchio codice, e perché preferisco passare istanze che
> id/righe... non è una motivazione molto pythonica?!
>
> Per quello ne ho capito io, _la_ funzionalità dell'ORM è mappare righe
> in oggetti... e non riesco a pensare ad un caso in cui _non_ ne abbia
> "bisogno veramente".

Mi sembra che Manlio parlasse di sqlalchemy core:
http://docs.sqlalchemy.org/en/rel_0_9/core/tutorial.html

forse ti ho frainteso, ma sqlalchemy è molto espressivo anche senza l'ORM


--

Message: 4
Date: Tue, 19 Nov 2013 16:10:05 +0100
From: Manlio Perillo 
To: python@lists.python.it
Subject: Re: [Python] O non capisco sqlite, o non capisco sqlalchemy,
 o entrambi
Message-ID: <528b7f4d.1020...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 19/11/2013 11:01, Pietro Battiston wrote:
> [...]
> A parte gli scherzi: non dico che l'ORM di SQLAlchemy sia _semplice_, ma
> non l'ho mai trovato tanto più complesso di quanto lo fossero le mie
> esigenze.
>
>> Un ultimo consiglio è di non usare l'ORM a meno di non aver bisogno
>> veramente delle sue funzionalità (ossia in quei casi in cui dovresti
>> reimplementarti le query non banali a mano); non è questo il tuo caso,
>> quindi usa sqlalchemy.schema e sqlalchemy.sql, che è comunque conveniente.
>>
>
> OK, OK, uso l'ORM perché non conosco SQL... ma _anche_ perché mi fa
> risparmiare parecchio codice, e perché preferisco passare istanze che
> id/righe... non è una motivazione molto pythonica?!
>

Che intendi?

> Per quello ne ho capito io, _la_ funzionalità dell'ORM è mappare righe
> in oggetti... e non riesco a pensare ad un caso in cui _non_ ne abbia
> "bisogno veramente".
>

Non hai bisogno di mappare tuple (nel senso usato in algebra 
relazionale) in oggetti.
L'oggetto che SQLAlchemy ti restituisce dopo una query è perfettamente 
usabile:

r = sql.select([my_table], where=[...]).fetchall()
for row in r:
   for col in row:
 print col

oppure:
for row in r:
print row['id'], row['rel']



Con l'ORM hai il vantaggio che ti "aggrega" le tuple delle tabelle 
"collegate", a seconda del tipo di relazione usata.  Nell'esempio fatto 
prima row['rel'] sarà l'id della colonna collegata se usi sqlalchemy 
core; con l'ORM sarà un dict-like contenente tutti i dati, oppure una 
sequenza di dict-like nel caso di relazioni uno a molti.

Ciao  Manlio


--

Message: 5
Date: Tue, 19 Nov 2013 15:58:22 +
From: enrico franchi 
To: Discussioni generali sul linguaggio Python
 
Subject: Re: [Python] Digest di Python, Volume 93, Numero 26
Message-ID:
 
Content-Type: text/plain; charset="iso-8859-1"

2013/11/19 Gollum1 

> Ma sono solo io che non riesco a capire le risposte ai messaggi nel
> formato digest? o chi scrive dovrebbe avere un po' più l'accortezza di
> eliminare quello che non serve, ed eventualmente avviare un nuovo
> thread e non rispondere ad un'altro che non c'entra nulla...
>

Molte persone badano più alla loro comodità che a quella dell'intera lista.
In più la gente non legge *nulla*.

Io personalmente uso un altro sistema: quando vedo queste cose,
semplicemente
*non* rispondo alla persona. Semplice: se la persona non ha tempo per
agevolarmi
nell'aiutare, io non ho tempo per aiutare.

-- 
.
..: -enrico-
-- parte 

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Simone Federici]

@Nicola
>
>  ORM is an anti-pattern
> 
>

Di anti pattern famosi ce ne sono tanti:
 - Spaghetti Code 

Ma ci sono anche quelli poco conosciuti
 - Links To Distractions 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Pietro Battiston]

Il giorno mar, 19/11/2013 alle 17.55 +0100, Manlio Perillo ha scritto:
> On 19/11/2013 17:30, Pietro Battiston wrote:
> > [...]
> >> oppure:
> >> for row in r:
> >>  print row['id'], row['rel']
> >
> >
> > Sì, questo mi è chiaro, ma a me piace più un
> >
> >  print mio_ogg.id, mio_ogg.rel
> >
> 
> La differenza tra
> 
> print row['id'], row['rel']
> 
> è solo di "facciata", specialmente se tieni conto che, in realtà, quello 
> che tu hai scritto è equivalente, in Python, a:
> 
> print mio_ogg.__dict__['id'], mio_ogg.__dict__['rel']


Sì, sì, certo! Ti sto solo dicendo quale facciata preferisco...


> > ... a te no?! Perché se sto parlando di utenti e loro informazioni, di
> > città e loro posizioni, e più in generale di oggetti e loro proprietà,
> > dovrei scrivere di righe e loro elementi?!
> >
> 
> Perchè è quello che realmente sono, visto che sono memorizzati in un 
> database relazionale.

... ma mi piacciono le facciate! Ovviamente, non tanto da sacrificare
l'efficienza.

> 
> E non si parla di righe e loro elementi, ma semplicemente di righe 
> (anche se il termine corretto sarebbe tupla).
> Anche con l'ORM ti restituisce una lista di oggetti, no?
> 

Certo... ma sono gli oggetti con cui sto ragionando, non altri necessari
per l'implementazione del mio ragionamento...


> > [...]
> > Appunto... e anche nei casi in cui (poniamo) non ho tabelle collegate,
> > con l'ORM la classe me la definisco io,
> 
> Perchè, la tabella SQL no?
> 

Beh, sì... ma se non sbaglio il python è un linguaggio ad oggetti, non a
tabelle :-)

> > posso aggiungerle dei metodi che
> > mi servono,
> 
> Puoi anche definire funzioni libere, che operano sulla tuple (perchè 
> tanto in Python i metodi sono funzioni libere, alla fine).

... ci deve essere davvero qualcosa di grosso che mi sfugge se, mentre
cerco di organizzare il mio codice in ordinate classi, un veterano (del
Vietnam? ;-) ) mi dice che in Python posso "anche definire funzioni
libere"...

> 
> > e farlo mano a mano che ne ho bisogno, posso definirla come
> > subclass di qualcos'altro,
> 
> L'ORM offre alcuni pattern complessi per diverse situazioni.
> Però, come ti ha detto Nicola, non è tutto "rose e fiori".
> 

OK, infatti ora mi leggo il materiale che ha passato.

> > posso tenere distinti più facilmente i
> > refactoring che eventualmente dopo un po' io volessi fare al codice che
> > lavora sugli oggetti e quelli che voglio fare alla struttura del
> > database (magari tutto ciò lo posso fare in qualche modo anche senza
> > l'ORM, ma l'ORM mi sembra lo strumento naturale, no?)...
> >
> 
> Se devi fare refactoring, ci sono metodi ben noti a livello di SQL.
> 

Non ne dubito...

> > ... poi ad un livello più di principio, per me l'ORM è ciò che permette
> > di usare un database ragionando ad oggetti, e la cosa, a meno di
> > controindicazioni che ancora mi sfuggono, mi piace.
> >
> 
> E' attrattivo certamente.
> Ma non bisogna abusarne; io ti ho avvertito poi sei libero di fare come 
> voi (ma il consiglio di imparare prima SQL resta, altrimenti se qualcosa 
> non funziona/è inefficiente avrai grosse difficoltà).
> 

Certo, la tua raccomandazione di capire cosa succede sotto è sacrosanta,
non lo metto assolutamente in dubbio (anche se il tradeoff tra quanto ti
studi l'implementazione delle librerie che usi e quanto tempo ti rimane
per fare quello che dovevi fare è particolarmente importante per chi non
programma di professione).

Quello che mi incuriosiva era solo lo step successivo, "evita ORM se
possibile"... e ora dovrei avere di che riflettere.

grazie!

Pietro

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Daniele Varrazzo]

On 2013-11-19 17:58, Pietro Battiston wrote:
Il giorno mar, 19/11/2013 alle 17.55 +0100, Manlio Perillo ha 
scritto:

On 19/11/2013 17:30, Pietro Battiston wrote:
> [...]
>> oppure:
>> for row in r:
>>  print row['id'], row['rel']
>
>
> Sì, questo mi è chiaro, ma a me piace più un
>
>  print mio_ogg.id, mio_ogg.rel
>

La differenza tra

print row['id'], row['rel']

è solo di "facciata", specialmente se tieni conto che, in realtà, 
quello

che tu hai scritto è equivalente, in Python, a:

print mio_ogg.__dict__['id'], mio_ogg.__dict__['rel']



Sì, sì, certo! Ti sto solo dicendo quale facciata preferisco...


L'interfaccia di quello che ottieni in Python (row.id, row.rel) è 
indipendente dagli strati sottostanti (usare o meno un orm). Puoi avere 
un driver che fa una query e restituisce un oggetto con gli attributi 
(es. psycopg2 con i NamedTupleCursor lo fa). Scrivere un wrapper che 
converte tuple/dizionari in oggetti è banale, molto più di un ORM.



> ... a te no?! Perché se sto parlando di utenti e loro 
informazioni, di
> città e loro posizioni, e più in generale di oggetti e loro 
proprietà,

> dovrei scrivere di righe e loro elementi?!
>

Perchè è quello che realmente sono, visto che sono memorizzati in un
database relazionale.


... ma mi piacciono le facciate! Ovviamente, non tanto da sacrificare
l'efficienza.


Usando una facciata senza sapere cosa c'è dietro il più delle volte la 
sacrifica, l'efficienza.





> [...]
> Appunto... e anche nei casi in cui (poniamo) non ho tabelle 
collegate,

> con l'ORM la classe me la definisco io,

Perchè, la tabella SQL no?



Beh, sì... ma se non sbaglio il python è un linguaggio ad oggetti, 
non a

tabelle :-)


Python non è integralista di alcun paradigma specifico. Ha anche 
funzioni che non sono metodi di oggetti: che fai, quelle non le usi 
perché è "a oggetti"?


Pensare che tutto sia un oggetto è una limitazione molto pesante nel 
contesto dei database. Tanto per buttarla lì: "quanti ordini ho evaso 
ieri?". "ci sono ordini inevasi più vecchi di una settimana"? Sono 
esempi di domande che non hanno bisogno di modellare l'ordine nella sua 
interezza. Usare un ORM per questo tipo di richieste produce query 
inefficienti.




> posso aggiungerle dei metodi che
> mi servono,

Puoi anche definire funzioni libere, che operano sulla tuple (perchè
tanto in Python i metodi sono funzioni libere, alla fine).


... ci deve essere davvero qualcosa di grosso che mi sfugge se, 
mentre
cerco di organizzare il mio codice in ordinate classi, un veterano 
(del

Vietnam? ;-) ) mi dice che in Python posso "anche definire funzioni
libere"...


OOP non vuol dire automaticamente buon design, soprattutto quando il 
problema non è inerentemente ad oggetti. E ORM non vuol dire 
automaticamente buon design, se in ambienti diversi (il codice e la base 
dati) il dominio si modella bene in maniera diversa. Dire "uso le classi 
quindi sto facendo bene" è più "ad una persona col martello ogni 
problema sembra un chiodo".


(per completezza cito anche JWZ: "once those database worms eat into 
your brain, it's hard to ever get anything practical done again. To a 
database person, every nail looks like a thumb. Or something like that")




Quello che mi incuriosiva era solo lo step successivo, "evita ORM se
possibile"... e ora dovrei avere di che riflettere.


Prego, rifletti pure. Ma fallo a mente aperta: se parti dai paradigmi

1. tutto è un oggetto
2. nel db ci sono solo oggetti

ovviamente arriverai alla conclusione che gli ORM sono l'invenzione 
migliore dopo il pane affettato. Prova con:


1. far diventare tutto un oggetto non è sempre utile
2. il modello relazionale è un soprainsieme del modello degli oggetti

e vedi come va.


-- Daniele

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Incuria, indifferenza, mancanza di rispetto

[Dario Bertini]

2013/11/19  :
> Grazie ragazzi, io non ho proprio capito il funzionamento di questa
> mail-list.
> per rispondere o porre un quesito devo cliccare su rispondi nella mia e-mail
> o cosa?
> Chiedo scusa se ho combinato qualche pasticcio nei post…attendo istruzioni
> Nel rispondere (io uso gmail) come edito l’oggetto?
> Grazie

si, hai combinato ancora qualche pasticcio

in breve:
1- vai su http://lists.python.it/mailman/listinfo/python e disabilita
l'iscrizione al digest... ti complica solo la vita
2- se ricevi un digest in futuro da un'altra mailing list, MAI
rispondere direttamente (a meno che tu non sappia come cambiare
l'oggetto, ma per caso ti dimentichi di farlo, meglio evitare comunque
il rischio)
3- se vuoi porre un quesito alla mailing list, puoi scrivere
direttamente all'indirizzo (che vedi in basso ad ogni mail inviata
tramite essa, assieme al link che t'ho dato prima)
4- per modificare l'oggetto della mail, dipende: può essere diverso in
ogni programma di posta che usi... prova ad installare thunderbird
(rispetto a gmail o il client di default di windows, hai il vantaggio
che l'UI è cambiata solo 1 o 2 volte durante la sua esistenza) oppure
http://www.mailpile.is/ che è scritto in Python :)
4b- non so per il client windows mail che usi, ma per gmail:
http://webapps.stackexchange.com/questions/40153/change-subject-line-in-new-gmail-compose-window
5- già che ci sei, invia mail in testo semplice invece che in html

se hai ancora problemi, google è tuo amico...

http://www.powersearchingwithgoogle.com (e diverse tecniche puoi
usarle anche con bing, duckduckgo o altri servizi )

per scrivere su una ML a contenuto tecnico, saper interagire
correttamente con un client di posta è un prerequisito, e non siamo
tenuti ad aiutarti oltre
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Digest di Python, Volume 93, Numero 36

[Daniele Zambelli]

Il 19 novembre 2013 18:14,   ha scritto:
> Grazie ragazzi, io non ho proprio capito il funzionamento di questa
> mail-list.

Si fa così:

Se devi scrivere a proposito di un nuovo argomento:
- clicchi sul pulsante "scrivi";
- metti come indirizzo: python@lists.python.it;
- scrivi un oggetto che in poche parole carattaerizzi l'argomento di
cui vuoi parlare;
- scrivi la mail cercando di esporre il problema nel modo più chiaro e
esauriente possibile facendo finta di non rivolgerti a delle persone
normali.

Se vuoi rispondere ad un messaggio che ti è arrivato dalla lista:
- Selezioni la frase (o le frasi) a cui vuoi rispondere;
- clicchi sul pulsante "rispondi";
- scrivi la tua risposta.

Ciao

-- 

Daniele

www.fugamatematica.blogspot.com

giusto!
nel verso
forse è perché non guardiamo le cose
Quando non ci capiamo,
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Marco Beri]

2013/11/19 Daniele Varrazzo 

> ovviamente arriverai alla conclusione che gli ORM sono l'invenzione
> migliore dopo il pane affettato. Prova con:
>
> 1. far diventare tutto un oggetto non è sempre utile
> 2. il modello relazionale è un soprainsieme del modello degli oggetti
>

Mamma mia. Oggi questa lista ha prodotto diverse perle (chiaramente IMHO).

Ed tutte gratis.

Meditate, gente, meditate.

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Daniele Palmese]

Il giorno 20 novembre 2013 00:36, Marco Beri  ha
scritto:

> Meditate, gente, meditate.
>
>
Più che meditate, godete...

Ciao.
Daniele
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python