Argomentazioni tecniche:
Personalmente, nonostante li eviti per mia natura, sono d'accordo
nell'usare
un ORM per la gestione delle query su database, in quanto permette di
astrarre
[snip]
nell'esecuzione di query di aggregazione dati SQLite risulta piu` lento di
Firebird in modalita`
2010/1/20 Carlos Catucci carlos.catu...@gmail.com:
Di mio uso Bazaar che trovo migliore anche di Mercurial, ma poi si sa il
sistema di versioning e' come la pizza, a ognuno il suo gusto
Curiosita`, com'e` a velocita` ora? Uno dei motivi per cui non ho mai
considerato Bzr e` che era lento come
Curiosita`, com'e` a velocita` ora? Uno dei motivi per cui non ho mai
considerato Bzr e` che era lento come la morte.
Io sto diventando un fan di Git ma credo che in ufficio forse
passeremo a Mercurial, prima o poi :-)
Io problemi non ne ho. Il fatto poi di avere i repo locali
2010/1/20 Carlos Catucci carlos.catu...@gmail.com:
Io problemi non ne ho. Il fatto poi di avere i repo locali (sincronizzabili)
e' per me il must. Git lo trovo troppo complesso e mancante dei repo locali.
Mercurial piu' complesso di Bazaar. Pero' ripeto, sono gusti. Tanto tra loro
(e con
* mercoledì 20 gennaio 2010, alle 14:27, Lawrence Oluyede scrive:
Per la questione feature: http://whygitisbetterthanx.com/
Io a suo tempo vidi questa:
http://versioncontrolblog.com/comparison/Bazaar/CVS/Git/Mercurial/Subversion/index.html
La discussione mi interessa molto perche' vorrei
Senza voler scatenare guerre di religione, ed anche essendo un pelo OT :-)
Nessuna guerra di religione. Io ho solo espresso il mio parere, asu o tempo
ho fatto uno studio sui tre prodotti ed ho scelto quello piu' idoneo alle
mie esigenze ( lavori di gruppo, spesso un membro del gruppo si puo'
Salve ho un dubbio..
se creo una lista di n dizionari
in questo modo
n=4
l=[{}]*n
ed poi voglio agire all'interno della lista
in questo modo
l[index][key]=3
dove index è un indice e key è una chiave
ho visto che il risultato è
[{key:4},{key:4},{key:4},{key:4},]
praticamente mi aggiorna
On Wed, 20 Jan 2010 18:13:37 +0100, Antonio Penta
penta.anto...@gmail.com
wrote:
Salve ho un dubbio..
se creo una lista di n dizionari
in questo modo
n=4
l=[{}]*n
ed poi voglio agire all'interno della lista
in questo modo
l[index][key]=3
dove index è un indice e key è una
2010/1/20 Daniele Varrazzo p...@develer.com
n=4
l=[{}]*n
Ti ha già spiegato Daniele cosa succede.
Aggiungo che per fare quello che vuoi fare questo è il modo giusto:
n=4
l= [ {} for i in range(n) ]
Ciao.
Marco.
--
http://ThinkCode.TV - Screencast e videocorsi di programmazione
Sera a tutti.
Mi chiedevo se esiste qualche interfaccia python verso le ultime versioni di
odbc. Il punto più interessante è che queste -stando alla doc- offrono la
possibilità di eseguire operazioni asincrone.
Altrimenti, se ho scritto una app in python che non è basata su twisted ma
volessi
Il giorno mer, 20/01/2010 alle 15.13 +0100, Carlos Catucci ha scritto:
Senza voler scatenare guerre di religione, ed anche essendo un
pelo OT :-)
Nessuna guerra di religione. Io ho solo espresso il mio parere, asu o
tempo ho fatto uno studio sui tre prodotti ed ho
Comunque, a parte la velocità, la cosa che mi ha fatto lasciare bazaar -
e mi incuriosisce sapere se è ancora così - è stata l'impossibilità di
tenere più branch in uno stesso repository, cosa che io trovo
estremamente comoda (se poi uno ci aggiunge la possibilità di avere un
colpo d'occhio
On 1/20/10 2:16 PM, Carlos Catucci carlos.catu...@gmail.com wrote:
MySql mi sembra una scelta altrettanto (se non di piu') valida.
Dal mio punto di vista MySQL è l'ultima scelta.
Appena prima di implementare tutto a mano.
___
Python mailing list
MySql mi sembra una scelta altrettanto (se non di piu') valida.
Dal mio punto di vista MySQL è l'ultima scelta.
Appena prima di implementare tutto a mano.
Ecco il problema di noi informatici. Ognuno ha il suo punto di vista. Quindi
o un progetto nasce con un owner (che so un benevolo
se la velocità / performance non sono un'aspetto limititante,
io vedrei di buon occhio l'adozione di sqlite.
Vero che MySql è più veloce di sqlite (... a mysql preferirei postgresql),
ma è anche vero che sqlite è molto più portabile di un vero e proprio db
relazionale.
con sqlite non c'è
Enrico Franchi wrote:
Dal mio punto di vista MySQL è l'ultima scelta.
Appena prima di implementare tutto a mano.
Ne ho visti che scambiano sinistra e destra, ma prima e dopo mai.
--
Nicola Larosa - http://www.tekNico.net/
The individual is not like his government. He cannot, for example,
On 1/20/10 9:56 PM, Nicola Larosa n...@teknico.net wrote:
Dal mio punto di vista MySQL è l'ultima scelta.
Appena prima di implementare tutto a mano.
Ne ho visti che scambiano sinistra e destra, ma prima e dopo mai.
Nel senso che implementarsi il db a mano viene prima di usare MySQL?
Enrico Franchi wrote:
Dal mio punto di vista MySQL è l'ultima scelta.
Appena prima di implementare tutto a mano.
Nicola Larosa wrote:
Ne ho visti che scambiano sinistra e destra, ma prima e dopo mai.
Enrico Franchi wrote:
Nel senso che implementarsi il db a mano viene prima di usare MySQL?
MEDICA2: [14] INTRODUZIONE ALLA VISITA
http://www.youtube.com/watch?v=rpwW2QLaZ5o
MEDICA2: [15] UN ESEMPIO DI RACCOLTA DI ANAMNESI
http://www.youtube.com/watch?v=5Np1IP1BBok
MEDICA2: [16] ANALISI DEL MENU SCHEDE SCRITTURA
http://www.youtube.com/watch?v=nteDswk06Lg
Prossimamente, tra l'altro:
Allo scopo di offrire anche a colleghi un punto di incontro per aprire
una discussione e un confronto con altri applicativi, e arricchire
eventualmente le idee e le soluzioni gia' esistenti, ho deciso di creare
questo gruppo:
http://www.facebook.com/group.php?v=infogid=260777389351
dove
On 1/21/10 7:44 AM, mauro mau...@iol.it wrote:
Potra' essere anche il luogo su cui annunciare l'eventuale nascita di
svilupppi del programma in veste nuova..
Sperando che tutti quelli che collaborano abbiano facebook.
Poi voglio dire, avete l'hosting su google, potete creare dozzine di
21 matches
Mail list logo
