[Python] R: Help Tkinter
[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
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
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
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
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 manlio.peri...@gmail.com 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
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!
Il 19 novembre 2013 08:55, Massimo Ceraldi max050...@gmail.com 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
Il 19 novembre 2013 08:55, Massimo Ceraldi max050...@gmail.com 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, python-requ...@lists.python.it 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 pal...@gmail.com To: Discussioni generali sul linguaggio Python python@lists.python.it Subject: [Python] [OT] Documentazione online Message-ID: [...] -- Message: 2 Date: Tue, 12 Nov 2013 22:09:01 +0100 From: Daniele Zambelli daniele.zambe...@gmail.com To: Discussioni generali sul linguaggio Python python@lists.python.it 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
2013/11/19 Pietro Battiston m...@pietrobattiston.it: 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
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
[Python] Incuria, indifferenza, mancanza di rispetto (era: Re: Digest di Python, Volume 93, Numero 26)
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)
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 n...@teknico.net È 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)
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] O non capisco sqlite, o non capisco sqlalchemy, o entrambi
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
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 http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern -- 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
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
@Nicola ORM is an anti-pattern http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern Di anti pattern famosi ce ne sono tanti: - Spaghetti Code http://c2.com/cgi/wiki?SpaghettiCode Ma ci sono anche quelli poco conosciuti - Links To Distractions http://c2.com/cgi/wiki?LinksToDistractions ___ 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
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
2013/11/19 max050...@gmail.com: 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
Il 19 novembre 2013 18:14, max050...@gmail.com 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
2013/11/19 Daniele Varrazzo p...@develer.com 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
Il giorno 20 novembre 2013 00:36, Marco Beri marcob...@gmail.com 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
