Re: [Python] python SQL?
2014-02-16 19:49 GMT+00:00 Diego Barrera : > Se le cose funzionano veramente cosi', certo. >> > Questo gia' potrebbe bastare :D Eh, ma non ci conterei... quello e' il fatto. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 16/02/2014 20:10, enrico franchi wrote: Se le cose funzionano veramente cosi', certo. Questo gia' potrebbe bastare :D Dalla strada arrivano notizie di tutti i tipi. C'e' twitter che riscrive tutto in Scala da Ruby. Ci sono quelli che invece falliscono perche' un competitor, sebbene arrivato secondo sul mercato, ci arriva con un prodotto che funziona *anche* sotto scala e gli utenti migrano in massa. Ci sono quelli che vanno avanti a zoppicare per anni e nessuno dice nulla. Spero di essere dell'ultimo tipo ;) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 20:15 GMT+01:00 enrico franchi : > Poi niente da dire, ci sono molti casi d'uso in cui il modello relazionale > non e' particolarmente indicato. Diciamo che di solito le cose "semplici" > spesso nascondono la complessita' da qualche altra parte. Sintesi perfetta. C'e' da dire che come economia di scala io viaggio in ordini di grandezza di certo abbatsanza piccoli da non dover scalare molto o spesso. Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 14:27 GMT+00:00 Carlos Catucci : > > A dire il vero ultimamente mi sono trovato con diversi progetti dove il > problema era proprio il modello relazionale. Va detto che si tratta di un > campione neppure lontanamente rappresentativo. Voglio dire anche se negli > ulltmi 4 progetti 3 venivano meglio con dei NoSql (piu' naturali le > costruzioni delle basi dati, piu' naturale usarle, aggiornarle, recuperare > i dati rapidamente etc.) 4 progetti non bastano per dire che nel 75% dei > casi sia cosi'. Facile che i prossimi 100 (se avro' la fortuna di lavorare > a tanti) potrenbbero essere meglio con il relazionale. > > La tentazione di usare una struttura piu' nested come quella di MongoDb > per fare certe cose e' sempre forte. Poi da vedere se paga o meno. > > Che dire... non sapendo le specifiche e' difficile parlarne. Il fatto e' che su molti nosql e' semplicemente piu' facile vomitare dati nella base di dati e tirarli fuori. Tutto questo e' molto semplice (perche' quasi non ti preoccupi del design della parte di persistenza). Poi quando le cose cominciano a rompersi, e' un flagello. Quando cominciano a finire dentro dati fatti troppo male e tu lo scopri qualche mese dopo, generalmente quando hai rimosso i log che ti avrebbero detto perche', e tipicamente alle quattro di mattina di sabato, quando ti suona il pager, e tu hai un hangover terrificante... Poi niente da dire, ci sono molti casi d'uso in cui il modello relazionale non e' particolarmente indicato. Diciamo che di solito le cose "semplici" spesso nascondono la complessita' da qualche altra parte. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 12:33 GMT+00:00 Diego Barrera : > On 16/02/2014 12:40, enrico franchi wrote: > >> >> L'architettura del db deve essere *sempre* il piu' efficiente possibile. >> Se no, non ja fa. E si, sharda, cazzi e mazzi, per carita'. >> >> Alla luce di questo e avendo in mente che devo andare in produzione il > prima possibile, > (leggi per ora mi interessa poco scalare, ma mi server avere una killer > app per vedere come va) > che succede se opero in questo modo: > > 1. creo model e tutta app con l'orm; > 2. l'app funziona e ho tanti clienti: primi problemi a scalare > 3. ottimizzo sql e impostazioni specifiche dbms > > Mi sembra un buon compromesso. > > Se le cose funzionano veramente cosi', certo. Solo che nella pratica non succede cosi'. Succede che fra il punto 2 e il punto 3 ci sono anche le nuove features, i bug fix, vari cazzi architetturali non previsti, tutta quella parte di operations che non sapevi che esistesse e che ti devi inventare, cominciare a mettere su team di risposta alle emergenze... Quindi tipicamente quello che fai al posto del 3 e' infilare un po' di patch, fare un po' di porcate con memcache etc etc etc. Dalla strada arrivano notizie di tutti i tipi. C'e' twitter che riscrive tutto in Scala da Ruby. Ci sono quelli che invece falliscono perche' un competitor, sebbene arrivato secondo sul mercato, ci arriva con un prodotto che funziona *anche* sotto scala e gli utenti migrano in massa. Ci sono quelli che vanno avanti a zoppicare per anni e nessuno dice nulla. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] setup bdist ==> error: can't copy 'ANIFEST.in': doesn't exist or not a regular file
Piergiuliano Bossi wrote: > Comunque un WTF tonante ci scappa per questa roba qua... Assolutamente. Purtroppo la comunità Python non sempre è riuscita a far prevalere la semplicità sulla tendenza alla sovraingegnerizzazione di alcuni, e conseguenti complicazioni inutili. La saga pluriennale dei vari distutils/setuptools/distribute/pip e compagnia ne è un esempio. In tutti questi anni non ho trovato la forza, né la necessità per fortuna, di approfondire veramente l'argomento. Un altro esempio è la programmazione web. Ci sono voluti anni per districarsi dall'abbraccio mortale di Zope 2, Zope 3 e Plone. Un altro ancora è la concorrenza. Ci sono voluti anni di asyncore, Twisted e Tornado, e finalmente l'interesse diretto del BDFL, per avere un supporto decente agli eventi asincroni nella libreria standard. Ma questo è un caso diverso dagli altri, probabilmente. -- Nicola Larosa - http://www.tekNico.net/ You can't take life that seriously. Life is here to serve you, and you are here to serve life. And if you are unhappy, what's the point? What's the point of having a life? - Erin Pavlina, 2009 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 02/16/2014 02:50 PM, Perini Matteo wrote: Tutti i controlli verranno fatti via sw appoggiandomi ad un db (sto propendendo per mongodb... ma non sono ancora sicuro) Te lo sconsiglio, non tanto per la mole dei dati (irrisoria, stiamo parlando di una decina di Mb all'anno), ma perche` non ti da nessun vantaggio evidente rispetto ad un RDBMS Ho visto un po' di differenze tra db relazionali e documentali e penso che per il mio caso non faccia molta differenza quale uso. (il numero di campi sarà fisso) Non e` la variabilita` dei campi a fare la differenza, ma la mappatura fra di loro. In un RDBMS e` fissa, in un Document Store e` variabile Non mi è invece molto chiaro come posso immagazzinare tutte le date/ora degli ingressi e uscite? suggerimenti? I RDBMS usano tipi di dati ad hoc, che ti permettono anche di eseguire operazioni su di loro. In alternativa, converti tutto in epoch e salvali in quel formato Come facilità d'uso cosa mi consigliate? mongodb? SQLite? Posto che "facilita` d'uso" in questo caso e` altamente improprio, ti consiglio di rimanere su PostgreSQL o su Firebird, in virtu` di come intendi procedere (e.g. su PostgreSQL hai piu` funzionalita`, su Firebird hai la manutenzione tendente allo zero) Dimenticavo... l'accesso al db avverrà sempre dallo stesso sw ma in due modi distinti, tramite la gui con richiesta dell'utente e, in automatico quando un utente "passa" la tessera con l'RFID, servirà prevedere thread per questo? Secondo me devi necessariamente prevedere due applicativi distinti, uno in ascolto costantemente sul db (ci sono delle metodologie su PostgreSQL che ti permettono di farlo senza fare polling continuo), l'altro che si connette solo quando serve (ovvero quando apro la gui) Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 18:39 GMT+01:00 Enrico Bianchi : > 'Sta cosa poteva avere senso prima del 2012, ovvero prima dell'avvento di > PostgreSQL 9.2, dove per la prima volta sono comparsi i campi JSON. Ad > oggi, nessuno ti vieta di avere una tabella con un solo campo JSON e > navigarla cosi`: > > SELECT json->"accessi" FROM tabella WHERE json->>"uid" = 1 > Vero, infatti mi hanno detto che PG abbia anche prestazioni superiori. Ah, poter avere tempo di studiare a fondo tutto. Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 02/16/2014 05:42 PM, Carlos Catucci wrote: Io trovo comoda la struttura json delle tabelle e il fatto che non abbia tabelle rigide. 'Sta cosa poteva avere senso prima del 2012, ovvero prima dell'avvento di PostgreSQL 9.2, dove per la prima volta sono comparsi i campi JSON. Ad oggi, nessuno ti vieta di avere una tabella con un solo campo JSON e navigarla cosi`: SELECT json->"accessi" FROM tabella WHERE json->>"uid" = 1 Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 17:39 GMT+01:00 Enrico Bianchi : > Dalla mia esperienza, non riesco a capire quale sia l'esatta collocazione > di MongoDB. E questo perche`, sempre nell'ottica di fargli gestire grosse > moli di dati, devi avere una configurazione che richiede almeno 9 (nove!) > nodi del database NoSQL. Di contro, con PostgreSQL mi basta una istanza per > avere prestazioni com Io trovo comoda la struttura json delle tabelle e il fatto che non abbia tabelle rigide. Per certi progetti ovvio. Ma non sono un esperto. Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 02/16/2014 03:41 PM, Carlos Catucci wrote: Io sapevo (ma posso sbagliarmi) che Mongo Db (che ribadisco quanto detto altrove trovo MLTO carino) era pensato per grosse moli di dati. Dalla mia esperienza, non riesco a capire quale sia l'esatta collocazione di MongoDB. E questo perche`, sempre nell'ottica di fargli gestire grosse moli di dati, devi avere una configurazione che richiede almeno 9 (nove!) nodi del database NoSQL. Di contro, con PostgreSQL mi basta una istanza per avere prestazioni comparabili Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] setup bdist ==> error: can't copy 'ANIFEST.in': doesn't exist or not a regular file
On Sunday 16 February 2014 10:24:35 Piergiuliano Bossi wrote: > Vedi > http://docs.python.org/2/distutils/examples.html#pure-python-distribution-by > -module > > Sono io che ho capito male, la documentazione e' sbagliata, o c'e' un bug? Hai ragione, era da un po' che non rileggevo il tutto! Uhm, prima di segnalare il bug (con tanto di relativo rant :D) dovresti però provare ad usare distutils nel tuo setup.py. Adesso setuptools dovrebbe esser migliorato, soprattutto dopo il merge di distribute[¹], in genere cerco sempre di utilizzare distutils a cui la documentazione che abbiamo guardato fa riferimento. Ed in effetti, e mi spiace non averci badato stamane (ma la domenica sono in modalità relax, soprattutto la mattina) questa sarebbe una PR migliore: eriol@mornie:~/tmp/simpyple$ git diff diff --git a/setup.py b/setup.py index aa31bb7..866338e 100644 --- a/setup.py +++ b/setup.py @@ -1,4 +1,4 @@ -from setuptools import setup +from distutils.core import setup import os import re Il commit log lo lascio a te, magari poi andrò a darvi un'occhiata su github! ;) Quindi, sì, forse è un bug, ma di setuptools: nella sua documentazione non trovo un riferimento al quel tipo di layout, ma ho cercato velocemente. Quindi non ho idea se è qualcosa di supportato o meno. Del resto da setuptools ho sempre visto importare find_package() (o un nome simile). [Daniele Tricoli] > > può non sembrare il massimo, ed anche a me ogni tanto viene da pensarci, > > ma > > poi mi dico che non vale la pena complicarsi la vita. > > Si' infatti non mi entusiasmava proprio quella struttura. Boh, ci penso, se > salta fuori qualche altra gabola causata dalla struttura certo che non ne > vale proprio la pena. In effetti usando distutils non dovrebbe spuntare imprevisti. Stavo ripensando al layout, ed in effetti in genere metto anche la documentazione nella root del repository (in genere una directory docs) ed avere la directory docs in mezzo al package principale non mi piace. Grazie per lo spunto di riflessione però, magari arriverò ad un layout migliore! Saluti, [¹] Per farti un'idea: http://python-notes.curiousefficiency.org/en/latest/pep_ideas/core_packaging_api.html che rimanda a https://python-packaging-user-guide.readthedocs.org/en/latest/future.html -- Daniele Tricoli 'Eriol' http://mornie.org ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] setup bdist ==> error: can't copy 'ANIFEST.in': doesn't exist or not a regular file
2014-02-16 16:26 GMT+01:00 Piergiuliano Bossi : > Penso che ci sarebbe un potenziale enorme per una piadineria decente a > Toronto. Ho trovato un paio di buone pizzerie, ma piadine ciccia. Potrei > vendere un figlio per una piadina buona, saranno 10 anni che non ne mangio > una... Purtroppo non sono da quelle parti. Pero' farsela a casa no? Scusate l'OT, ma come dissero Aldo, Giovanni e Giacomo: Il cibo degli dei, la piaDEIna ;) Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] setup bdist ==> error: can't copy 'ANIFEST.in': doesn't exist or not a regular file
On Sun, Feb 16, 2014 at 3:04 AM, Carlos Catucci wrote: > > 2014-02-14 22:47 GMT+01:00 Piergiuliano Bossi : > >> error: can't copy 'ANIFEST.in': doesn't exist or not a regular file > > > A naso pero' > > error: can't copy 'ANIFEST.in': doesn't exist or not a regular file > > ANIFEST? Non e' che manca una M all'inizio da qualche parte? > > C'avevo pensato anch'io, ma niente, non e' quello. E comunque vedi la risposta (santa) di Daniele Tricoli. Comunque un WTF tonante ci scappa per questa roba qua... Ciao, Giuliano -- Piergiuliano Bossi Blog: http://thinkingbox.wordpress.com/ Twitter: http://twitter.com/thinkingbox (English) Twitter: http://twitter.com/scatolapensante (Italiano) Google+: https://plus.google.com/u/0/108187981162465525118 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] setup bdist ==> error: can't copy 'ANIFEST.in': doesn't exist or not a regular file
2014-02-16 3:03 GMT-05:00 Carlos Catucci : > > 2014-02-14 22:47 GMT+01:00 Piergiuliano Bossi : > >> Cosa sto sbagliando? Professione? Meglio dedicarmi alle pizze? > > > Guarda se kl amettiamo sul guadagnare di piu' ti dico che io da tempo > sogno di mettermi a fare il piadinaro, pero' sai com'e', come dice il detto: > Penso che ci sarebbe un potenziale enorme per una piadineria decente a Toronto. Ho trovato un paio di buone pizzerie, ma piadine ciccia. Potrei vendere un figlio per una piadina buona, saranno 10 anni che non ne mangio una... > > "Si e' vero, sono un informatico, ma e' sempre meglio che lavorare". ;) > Mi spiace solo di non essere in grado di aiutarti per la cosa, pero'. La > cosa inteso come la libreria, non le pizze. > > Eh eh :) Ciao, Giuliano -- Piergiuliano Bossi Blog: http://thinkingbox.wordpress.com/ Twitter: http://twitter.com/thinkingbox (English) Twitter: http://twitter.com/scatolapensante (Italiano) Google+: https://plus.google.com/u/0/108187981162465525118 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] setup bdist ==> error: can't copy 'ANIFEST.in': doesn't exist or not a regular file
2014-02-16 4:05 GMT-05:00 Daniele Tricoli :
> [...]
> Premesso che non ho indagato a fondo anche perché in genere cerco di
> evitare
> setuptools, quindi non ti so dire perché MANIFEST.in diventi ANIFEST.in
> però
> ho notato una cosa.
>
> Nel tuo setup.py scrivi:
>
> [...]
> packages=['simpyple'],
> [...]
>
> Cioè stai dicendo che esisterà simpyple/__init__.py, ma il layout del tuo
> progetto è diverso in quanto il tuo package è nella stessa directory di
> setup.py, per cui al posto di package_dir={'simpyple': ''}, in effetti
> dovresti dare package_dir={'simpyple': '.'},
>
> Infatti con (non ti mando una PR, ma ti incollo qui la diff):
> [...]
>
Ma sei MERAVIGLIOSO!!! :D
Pero' qui dovrebbe scattare un rant. Leggendo la documentazione, quando
parla di un progetto strutturato come il mio, dice:
> (The empty string also stands for the current directory.)
Vedi
http://docs.python.org/2/distutils/examples.html#pure-python-distribution-by-module
Sono io che ho capito male, la documentazione e' sbagliata, o c'e' un bug?
> [...]
> (Scusa il wordwrap, ma il log penso renda l'idea).
>
>
Si' si', perfetto grazie.
> Trovi informazioni dettagliate sulla cosa qui:
> http://docs.python.org/2/distutils/setupscript.html
Eh, ma vedi sopra: li' avevo attinto le mie informazioni.
> Forse ti conviene utilizzare un layout più convenzionale sia per evitare
> sorprese del genere, ma anche per seguire il POLA, in effetti pure non ho
> notato a colpo d'occhio che il package si trovava allo stesso livello di
> setup.py.
> È vero, avere il repository col path del package
>
> simpyple/simpyple/__init__.py
> ...
> setup.py
>
> può non sembrare il massimo, ed anche a me ogni tanto viene da pensarci, ma
> poi mi dico che non vale la pena complicarsi la vita.
>
Si' infatti non mi entusiasmava proprio quella struttura. Boh, ci penso, se
salta fuori qualche altra gabola causata dalla struttura certo che non ne
vale proprio la pena.
>
> Ah, magari vuoi impostare il tuo editor in modo che rimuova i trailing
> space:
> ci sono un paio di righe nel setup.py che contengono solo uno spazio... per
> fortuna nel mio vimrc non uso uso l'impostazione "mostrami le lacrime di
> sangue al posto dei trailing space" come usa(va) fare Marco Beri! ;-)
>
>
Si', anche se... "the question is: who cares?" :)
Non sono di certo un purista del pep8, soprattutto quando si tratta di
linee vuote a trailing spaces, ma vabbeh.
HTH,
>
>
Molto. :)
Grazie e ciao
Giuliano
--
Piergiuliano Bossi
Blog: http://thinkingbox.wordpress.com/
Twitter: http://twitter.com/thinkingbox (English)
Twitter: http://twitter.com/scatolapensante (Italiano)
Google+: https://plus.google.com/u/0/108187981162465525118
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 16:16 GMT+01:00 Carlos Catucci : > Sebbene molti ORM supportino dei NoSql (Django almeno mi sembra > lo faccia con MongoDb) > No, l'ORM di Django non lo supporta ma c'è un fork che lo fa: http://django-nonrel.org/ Ciao -- M. http://2014.djangovillage.it/ :: http://tinkergarage.it/ ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 16:01 GMT+01:00 Manlio Perillo : > Nulla di male, ma ORM significa Object *Relational* Mapper :) > > Quindi sospetto tu abbia quotato la parte sbagliata del mio messaggio. > Perdonami, avevo deviato, dall'ORM in se ai modelli in generale, discorso ripreso poi. Sebbene molti ORM supportino dei NoSql (Django almeno mi sembra lo faccia con MongoDb) Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 16/02/2014 15:27, Carlos Catucci wrote: 2014-02-16 14:04 GMT+01:00 Manlio Perillo mailto:manlio.peri...@gmail.com>>: Riguardo i gusti personali, gli ORM poi non mi piacciono perchè li reputo una astrazione "sbagliata" sopra il modello relazionale. A dire il vero ultimamente mi sono trovato con diversi progetti dove il problema era proprio il modello relazionale. Nulla di male, ma ORM significa Object *Relational* Mapper :) Quindi sospetto tu abbia quotato la parte sbagliata del mio messaggio. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 14:50 GMT+01:00 Perini Matteo : > sto seguendo con interesse ma il livello si è alzato un po' ;) > Sai come finiscono ste cose, uno fa una domanda innocente (la mia sugli orm) e ne viene fuori una tavola rotonda. Pero' fa sempre bene ascoltare chi ne sa di piu', pure se, come mi sta accdendo in qualche passaggio, devi prima googlare un poco solo per avere idea vaga di cosa stiano dicendo ;) > Cerco di spiegarvi cosa vorrei fare. > Per adesso si tratta di una piccola applicazione per tener traccia di > accessi e pagamenti per una associazione. > > Scenario: > Qualche centinaio di utenti avranno una carta RFID (codice univoco) con la > quale potranno accedere alla sala dell'associazione. > Ad ogni codice nel db corrisponderà l'anagrafica, numeri di telefono ecc, > una decina di cose specifiche dell'associazione. > Oltre a questo, ogni ingresso/uscita andrebbe immagazzinato da qualche > parte. > All'ingresso vi sarà anche un controllo se l'utente è in regola con i > pagamenti delle quote associative. > Gli utenti possono essere di vario tipo (studenti/Adulti/pensionati) con > vari tipi di possibile associazione (mensile/annuale/n°di ingressi). > Tutti i controlli verranno fatti via sw appoggiandomi ad un db (sto > propendendo per mongodb... ma non sono ancora sicuro) > Io sapevo (ma posso sbagliarmi) che Mongo Db (che ribadisco quanto detto altrove trovo MLTO carino) era pensato per grosse moli di dati. > > Ho visto un po' di differenze tra db relazionali e documentali e penso che > per il mio caso non faccia molta differenza quale uso. (il numero di campi > sarà fisso) > Cosa che porta piu' verso il relazionale, o meglio, che e' caratteristica buona per un relazionale (*). > Anche i tempi delle varie query penso siano insignificanti in entrambi i > casi visto che si parla di qualche migliaio di dati. > Non mi è invece molto chiaro come posso immagazzinare tutte le date/ora > degli ingressi e uscite? suggerimenti? > Campi appositi di tipo date/time? (magari adesso mi darai del'idiota, ma possibile che non abbia capito bene la domanda). Come facilità d'uso cosa mi consigliate? mongodb? SQLite? > Sono tutti facili e tutti difficili. Il mio consiglio, basato sulla mia teoria che il miglior editor/ide/linguaggio/db/etc. e' quello con cui ti trovi meglio) e' di provare entrambi, giocarci un poco e poi decidere. > Dimenticavo... l'accesso al db avverrà sempre dallo stesso sw ma in due > modi distinti, tramite la gui con richiesta dell'utente e, in automatico > quando un utente "passa" la tessera con l'RFID, servirà prevedere thread > per questo? > Dipende da quanti user contemporaneamente accedono. > Grazie dell'aiuto (anche di domenica) > la domenica e' un giorno come gli altri se non sei un fanatico religioso. ;) * Per un progetto (che dorme nel cassetto da anni) avevo necessita' di tabelle che potevano avere un numero di campi variabili. Volevo pero' evitare una tabella correlata "1 a molti" per motivi di performance. Ed ero ricorso ad una tabella a 4 campi (va beh, tra id autoincrementale e altri accessori erano di piu' ma quelli importanti erano 4) e per la precisione identificatore della transazione (raggruppamento) tipologia dell'oggetto nome dell'oggetto valore dell'oggetto Si tratta di una applicazione per immobiliari, il primo campo era riferito alla proposta immobiliare, il secondo mi diceva se si trattava di prezzi, tipologie di transazione, descrizione di accessori, etc, il terzo era il nome dell'oggetto in se e l'ultimo il suo valore. Con un dirty trick riuscivo ad cercare proposte immobiliari variegate (esempio offerte in affitto di appartamenti con 3 camere, 2 bagni, posto auto, riscaldamento autonomo, tra il 2ndo ed il 4to piano, non attici, in una data zona e ad un prezzo massimo di x) ma era davvero una query poco ortodossa (una sommatoria di variabili messe a 1 se caratteristica presente). Poi ho scoperto MongoDb e tutto e' stato rivisitato in maniera naturale. Pero' e' un caso specifico dove la stessa proprieta' immobiliare puo' presentare un range di caratteristiche di cui alcune comuni (prezzo, indirizzo, tipologia), altre specifiche del tipo (un garage non avra' ascensore o giardino) ed altre ancora magari presenti solo per quella proposta (un appartamento con giardino pensile per dire). Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 14:04 GMT+01:00 Manlio Perillo : > Riguardo i gusti personali, gli ORM poi non mi piacciono perchè li reputo > una astrazione "sbagliata" sopra il modello relazionale. A dire il vero ultimamente mi sono trovato con diversi progetti dove il problema era proprio il modello relazionale. Va detto che si tratta di un campione neppure lontanamente rappresentativo. Voglio dire anche se negli ulltmi 4 progetti 3 venivano meglio con dei NoSql (piu' naturali le costruzioni delle basi dati, piu' naturale usarle, aggiornarle, recuperare i dati rapidamente etc.) 4 progetti non bastano per dire che nel 75% dei casi sia cosi'. Facile che i prossimi 100 (se avro' la fortuna di lavorare a tanti) potrenbbero essere meglio con il relazionale. La tentazione di usare una struttura piu' nested come quella di MongoDb per fare certe cose e' sempre forte. Poi da vedere se paga o meno. Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 16/02/2014 14:50, Perini Matteo wrote: Il 16/02/2014 14:04, Manlio Perillo ha scritto: Perchè, in questo caso specifico, un ORM è una bestia molto complessa, e consigliarlo ad uno che adesso sta cominciando con i database relazionali non è una buona cosa. Ciao, sto seguendo con interesse ma il livello si è alzato un po' ;) Puoi tranquillamente ignorare i punti più complessi ;) Cerco di spiegarvi cosa vorrei fare. Per adesso si tratta di una piccola applicazione per tener traccia di accessi e pagamenti per una associazione. Scenario: Qualche centinaio di utenti avranno una carta RFID (codice univoco) con la quale potranno accedere alla sala dell'associazione. Ad ogni codice nel db corrisponderà l'anagrafica, numeri di telefono ecc, una decina di cose specifiche dell'associazione. Oltre a questo, ogni ingresso/uscita andrebbe immagazzinato da qualche parte. [...] Ho visto un po' di differenze tra db relazionali e documentali e penso che per il mio caso non faccia molta differenza quale uso. (il numero di campi sarà fisso) Anche i tempi delle varie query penso siano insignificanti in entrambi i casi visto che si parla di qualche migliaio di dati. Un database server come PostgreSQL offre molta flessibilità. Semplicemente lo installi su un server (magari separato da quello dove si trova il client, e gestito in modo da avere una buona sicurezza e backup); questo è uno dei vantaggi rispetto ad esempio ad SQLite. Personalmente mi allontanerei dal modello relazionale *solo* se fa differenza quale modello uso. Non mi è invece molto chiaro come posso immagazzinare tutte le date/ora degli ingressi e uscite? suggerimenti? Non mi sembra complesso. Quale problema vedi? Come facilità d'uso cosa mi consigliate? mongodb? SQLite? Devi innanzitutto distinguere tra modelli di dati. mongodb e SQLite usano modelli di dati differenti. Per una differenza tra i vari modelli, vedi le pagine di wikipedia per mongodb e PostgreSQL, in particolare: http://en.wikipedia.org/wiki/Document-oriented_database http://en.wikipedia.org/wiki/Relational_database Sono argomenti abbastanza ampi, inizia a documentarti e magari se hai dubbi chiedi. Tieni presente che sto assumendo tu voglia imparare ad usare un database. In alternativa puoi anche iniziare leggendo la parte introduttiva della documentazione di PostgreSQL o mongodb. Se ti va bene il modello relazionale, SQLite è sicuramente più semplice di PostgreSQL (e lo hai incluso in Python), ma ha diverse limitazioni. Dimenticavo... l'accesso al db avverrà sempre dallo stesso sw ma in due modi distinti, tramite la gui con richiesta dell'utente e, in automatico quando un utente "passa" la tessera con l'RFID, servirà prevedere thread per questo? Cosa intendi? > [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
Il 16/02/2014 14:04, Manlio Perillo ha scritto: Perchè, in questo caso specifico, un ORM è una bestia molto complessa, e consigliarlo ad uno che adesso sta cominciando con i database relazionali non è una buona cosa. Ciao, sto seguendo con interesse ma il livello si è alzato un po' ;) Cerco di spiegarvi cosa vorrei fare. Per adesso si tratta di una piccola applicazione per tener traccia di accessi e pagamenti per una associazione. Scenario: Qualche centinaio di utenti avranno una carta RFID (codice univoco) con la quale potranno accedere alla sala dell'associazione. Ad ogni codice nel db corrisponderà l'anagrafica, numeri di telefono ecc, una decina di cose specifiche dell'associazione. Oltre a questo, ogni ingresso/uscita andrebbe immagazzinato da qualche parte. All'ingresso vi sarà anche un controllo se l'utente è in regola con i pagamenti delle quote associative. Gli utenti possono essere di vario tipo (studenti/Adulti/pensionati) con vari tipi di possibile associazione (mensile/annuale/n°di ingressi). Tutti i controlli verranno fatti via sw appoggiandomi ad un db (sto propendendo per mongodb... ma non sono ancora sicuro) Ho visto un po' di differenze tra db relazionali e documentali e penso che per il mio caso non faccia molta differenza quale uso. (il numero di campi sarà fisso) Anche i tempi delle varie query penso siano insignificanti in entrambi i casi visto che si parla di qualche migliaio di dati. Non mi è invece molto chiaro come posso immagazzinare tutte le date/ora degli ingressi e uscite? suggerimenti? Come facilità d'uso cosa mi consigliate? mongodb? SQLite? Dimenticavo... l'accesso al db avverrà sempre dallo stesso sw ma in due modi distinti, tramite la gui con richiesta dell'utente e, in automatico quando un utente "passa" la tessera con l'RFID, servirà prevedere thread per questo? Scusate se non ho chiarito prima questi punti che avrebbero potuto aiutarvi ad aiutarmi ma da non avevo proprio idea di come partire. Grazie dell'aiuto (anche di domenica) Ciao M. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 15/02/2014 20:55, Carlos Catucci wrote: 2014-02-15 19:56 GMT+01:00 Manlio Perillo mailto:manlio.peri...@gmail.com>>: ma senza l'ORM, solo sqlalchemy.sql Per curiosita' da ignorante, ma perche' non l'ORM? Non ti piaciono gli orm o e' un qualcosa di SQLAllchemy in particolare che non va? Perchè, in questo caso specifico, un ORM è una bestia molto complessa, e consigliarlo ad uno che adesso sta cominciando con i database relazionali non è una buona cosa. Riguardo i gusti personali, gli ORM poi non mi piacciono perchè li reputo una astrazione "sbagliata" sopra il modello relazionale. > [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
per cose piccole, SQLite Il giorno 16 febbraio 2014 13:33, Diego Barrera ha scritto: > On 16/02/2014 12:40, enrico franchi wrote: > >> >> L'architettura del db deve essere *sempre* il piu' efficiente possibile. >> Se no, non ja fa. E si, sharda, cazzi e mazzi, per carita'. >> >> Alla luce di questo e avendo in mente che devo andare in produzione il > prima possibile, > (leggi per ora mi interessa poco scalare, ma mi server avere una killer > app per vedere come va) > che succede se opero in questo modo: > > 1. creo model e tutta app con l'orm; > 2. l'app funziona e ho tanti clienti: primi problemi a scalare > 3. ottimizzo sql e impostazioni specifiche dbms > > Mi sembra un buon compromesso. > > ___ > Python mailing list > Python@lists.python.it > http://lists.python.it/mailman/listinfo/python > ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 16/02/2014 12:40, enrico franchi wrote: L'architettura del db deve essere *sempre* il piu' efficiente possibile. Se no, non ja fa. E si, sharda, cazzi e mazzi, per carita'. Alla luce di questo e avendo in mente che devo andare in produzione il prima possibile, (leggi per ora mi interessa poco scalare, ma mi server avere una killer app per vedere come va) che succede se opero in questo modo: 1. creo model e tutta app con l'orm; 2. l'app funziona e ho tanti clienti: primi problemi a scalare 3. ottimizzo sql e impostazioni specifiche dbms Mi sembra un buon compromesso. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 7:51 GMT+00:00 Carlos Catucci : > > De gustibus non disputandum est. > Sulle cose tecniche di solito non e' questione di *gusti*. Ci sono due questioni principali. Una completamente filosofica: 1. Ci sono un botto di pattern architetturali per fare ORM. I piu' popolari fuori da casa ms sono active record e data mapper. Guarda caso, nessuno dei due e' perfetto. Il motivo e' che il problema di mappare il modello relazionale sul modello ad oggetti e' vagamente ill-defined per vari motivi (fra cui il fatto che il modello ad oggetti e' un pochetto ill-defined di suo e soprattutto tende ad ammettere piu' soluzioni ad uno stesso problema con differenti trade-offs). Per cui anche a livello teorico si hanno vari compromessi... e.g., il design di active record e' molto leaky, data mapper e' relativamente complesso concettualmente. Ma poi proprio semplicemente ci sono cose molto naturali nel mondo ad oggetti che si mappano malissimo nel mondo relazionale e viceversa. E per queste situazioni l'orm non e' che puo' fare davvero molto... La seconda molto pratica: quello che e' un ORM e' un oggetto appiccicato sopra uno dei colli di bottiglia tipici delle applicazioni. Il che vuole dire che e' veramente molto sensibile alle performance. E semplifica molto la scrittura di query inefficienti. Ora, come si puo' notare dalla permanenza in una qualunque lista come questa, se le persone hanno una feature vagamente comoda da usare, ne abuseranno inconsapevolmente, insegneranno ad altri il loro trucco e poi si lamenteranno che tutto va piano (appena i dati crescono). Siccome sono clueless, ovviamente non avranno idea di quello che e' successo e risolveranno in vari modi (prendendo un consulente, generalmente per un altro linguaggio, cambieranno database, riscriveranno tutto, andranno avanti a lamentarsi senza fare nulla, dando la colpa a componenti casuali dell'architettura). Ora in tutto questo non e' che ci sia nulla di male, semplicemente il fatto e' che cose facili da fare e drammaticamente inefficienti saranno fatte *inconsapevolmente*. Il punto chiave e' che la gente pensa architetture varie ad oggetti e sfruttera' la flessibilita' dell'orm per martellarci dentro il pattern di accesso ai dati che piu' gli pare, non necessariamente uno buono. Su tutto questo, si infila il problemino tipico dei linguaggi ad oggetti: i dati occupano quintali di memoria non necessaria perche' sono pesantemente nested. E avere un sistema comodo per generare una comoda interfaccia ad oggetti vuole dire che le cose saranno fatte cosi'. E voglio dire... ricordati che i dati nel db sono, auspicabilmente univoci. tipicamente hai un db per applicazione, dentro cui hai i dati. un db logico: potrebbe essere shardato, auspicabilmente e' replicato, etc etc etc. I dati sono li e non danno fastidio. Poi scopri che hai una piccola flotta di server. Ciascuno di questi tira su un po' di worker. Ed ecco che le query che ti tirano su x MB di oggetti, in realta' finisce che ti tirano su x00 MB *globalmente*. E cominci ad avere problemi. E si, memcache, orpelli, cazzi e mazzi. Oh, poi voglio dire, se hai un magazzino con duemila oggetti, chissene. Se devi fare il payroll per duecento dipendenti, chissene. Se devi fare il blog, il forum e chissene... il problema e' che non scala. Non scala. Non ci sono cazzi. > Io personalmente li trovo comodi. Il non dover impazzire tra dialetti, il > poter svilupppare in locale, per dire, su Sqlite e poi andare in produzione > con Postgres, cosa che mi facilita di molto le cose (per dirne una se > aggiungo dati di test alla base dati un push sul repo condiviso (*) rende > disponibile la cosa a tutti i coinvolti nel progetto senza dover eseguire > un dump da allegare e un db_restore dopo un pull) senza impazzire sui > dialetti e sulle varie differenze (sacrosante, ciascun Db ha il suo motivo > di esistere, di essere specializzato in qualcosa, tranne forse un paio). > Comodo, forse. Stiamo pero' contando *molto* che l'astrazione sia perfetta e non si stia nascondendo un baco che ti comparira' sulle macchine di test o addirittura in produzione. Vuole anche dire che non puoi usare nulla di specifico di PostgreSQL, che, sebbene accettabile, e' comunque una forte limitazione. Poi ovvio che se devo fare una query particolarmente incasinata (e accade > SOLO se lavoro su basi dati esistenti, in caso contrario se e' roba mia > parto dal presupposto di avere sbagliato l'architettura e riprogetto di > conseguenza) posso usrae una raw, ma deve essere davvero un caso limite > dove l'ORM non ce la fa. > L'architettura del db deve essere *sempre* il piu' efficiente possibile. Se no, non ja fa. E si, sharda, cazzi e mazzi, per carita'. Il problema e' che anche su query relativamente semplici succedono cose. > > Lo so, mi direte che l'ORM non ottimizza come puo' fare una query scritta > ad hoc, ma a volte la flessibilita' conta piu' delle prestazioni. > Non nel mio caso. Aggiungere host non necessari cessa di scalar
Re: [Python] python SQL?
On Sunday 16 February 2014 10:35:51 Carlos Catucci wrote: > Beh che vuoi, nessuno e' perfetto ;) Mai detto il contrario! :-) > Comunque posso fare una macchina di test uguale a quella di produzione da > subito e fare le prove, pero' per il quotidiano se il progetto e' > condiviso, aiuta. Sì certo, il mio pensiero, appunto è che bisogna comunque conoscere il tradeoff che si fa utilizzando una determinata soluzione, soprattutto visto che l'OP si sta affacciando per la prima volta su questo specifico argomento. L'ORM ti dà flessibilità, ma ti "nasconde" feature specifiche di un determinato database, e la domanda da porsi, IMHO, è: quanto costa tale flessibilità? E quanto senso ha accettare tale costo? Per la maggior parte dei progetti il costo sarà anche nullo (anche in termini di debito tecnologico), ma non possiamo escludere che in alcuni casi la flessibilità di poter cambiare database di produzione è una feature che non verrà mai sfruttata. :-) Per quanto riguarda il testing, nel caso in cui lavorassimo ad un progetto insieme ti proporrei, al posto di un database SQLite da condividere, di usare un ORM (così si fa in fretta :D) per creare delle testsuite al volo (da poi integrare correttamente però) per poter dire cose del tipo: «Carlos, dai un'occhiata a sandobox/eriol/test_for_1234.py?» Dove test_for_1234.py andrebbe a mettere in evidenza il problema creando da zero il database e riempiendolo[¹]. Uno dei vantaggi che mi viene subito in mente è che nel caso in cui stessimo indagando problemi diversi che impattano la stessa parte del database, possiamo condividere il problema senza dover condividere due db SQLite, ad esempio. Ma la parte più importante è l'essersi messi d'accordo tra noi su come fare il testing condiviso! :-) Buona domenica, [¹] niente fixture please ;-) -- Daniele Tricoli 'Eriol' http://mornie.org ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 10:15 GMT+01:00 Daniele Tricoli : > ... e ti fa attendere il deploy sullo staging server per scoprire eventuali > problemi legati all'uso di un database diverso da quello di produzione! :-) > Beh che vuoi, nessuno e' perfetto ;) Comunque posso fare una macchina di test uguale a quella di produzione da subito e fare le prove, pero' per il quotidiano se il progetto e' condiviso, aiuta. Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] setup bdist ==> error: can't copy 'ANIFEST.in': doesn't exist or not a regular file
On 16 Feb 2014 10:05, "Daniele Tricoli" wrote: > per fortuna nel mio vimrc non uso uso l'impostazione "mostrami le lacrime di > sangue al posto dei trailing space" come usa(va) fare Marco Beri! ;-) Veramente lo faccio ancora... :-) Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
Ciao Carlos, On Sunday 16 February 2014 08:51:36 Carlos Catucci wrote: > il poter svilupppare in locale, per dire, su > Sqlite e poi andare in produzione con Postgres, cosa che mi facilita di > molto le cose ... e ti fa attendere il deploy sullo staging server per scoprire eventuali problemi legati all'uso di un database diverso da quello di produzione! :-) -- Daniele Tricoli 'Eriol' http://mornie.org ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] setup bdist ==> error: can't copy 'ANIFEST.in': doesn't exist or not a regular file
Ciao Piergiuliano,
On Friday 14 February 2014 16:47:35 Piergiuliano Bossi wrote:
> Mi sto spaccando le corna su una cosa che immagino essere stupida e banale
> e mi fara' sentire piccolo e misero di fronte all'universo.
No dai, può capitare a tutti! Il bello di liste come questa è appunto poter
discutere con altri che hanno la stessa tua passione anche su cose
apparentemente incomprensibili come questa! :)
[CUT output of $ python setup.py bdist]
> error: can't copy 'ANIFEST.in': doesn't exist or not a regular file
>
> Inoltre, se uno prova a installare il sorgente (attualmente pubblicato) con
> pip install ottiene lo stesso errore.
Premesso che non ho indagato a fondo anche perché in genere cerco di evitare
setuptools, quindi non ti so dire perché MANIFEST.in diventi ANIFEST.in però
ho notato una cosa.
Nel tuo setup.py scrivi:
[...]
packages=['simpyple'],
[...]
Cioè stai dicendo che esisterà simpyple/__init__.py, ma il layout del tuo
progetto è diverso in quanto il tuo package è nella stessa directory di
setup.py, per cui al posto di package_dir={'simpyple': ''}, in effetti
dovresti dare package_dir={'simpyple': '.'},
Infatti con (non ti mando una PR, ma ti incollo qui la diff):
eriol@mornie:~/tmp/simpyple$ git diff
diff --git a/setup.py b/setup.py
index aa31bb7..9faddff 100644
--- a/setup.py
+++ b/setup.py
@@ -45,7 +45,7 @@ setup(
author_email='',
url='https://github.com/thinkingbox/simpyple',
license='',
-package_dir={'simpyple': ''},
+package_dir={'simpyple': '.'},
packages=['simpyple'],
include_package_data=True,
zip_safe=False,
eriol@mornie:~/tmp/simpyple$ python setup.py bdist
running bdist
running bdist_dumb
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/simpyple
copying ./schedule.py -> build/lib.linux-x86_64-2.7/simpyple
copying ./__init__.py -> build/lib.linux-x86_64-2.7/simpyple
running egg_info
creating simpyple.egg-info
writing requirements to simpyple.egg-info/requires.txt
writing simpyple.egg-info/PKG-INFO
writing top-level names to simpyple.egg-info/top_level.txt
writing dependency_links to simpyple.egg-info/dependency_links.txt
writing manifest file 'simpyple.egg-info/SOURCES.txt'
reading manifest file 'simpyple.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'simpyple.egg-info/SOURCES.txt'
installing to build/bdist.linux-x86_64/dumb
running install
running install_lib
creating build/bdist.linux-x86_64
creating build/bdist.linux-x86_64/dumb
creating build/bdist.linux-x86_64/dumb/usr
creating build/bdist.linux-x86_64/dumb/usr/local
creating build/bdist.linux-x86_64/dumb/usr/local/lib
creating build/bdist.linux-x86_64/dumb/usr/local/lib/python2.7
creating build/bdist.linux-x86_64/dumb/usr/local/lib/python2.7/dist-packages
creating build/bdist.linux-x86_64/dumb/usr/local/lib/python2.7/dist-
packages/simpyple
copying build/lib.linux-x86_64-2.7/simpyple/schedule.py -> build/bdist.linux-
x86_64/dumb/usr/local/lib/python2.7/dist-packages/simpyple
copying build/lib.linux-x86_64-2.7/simpyple/__init__.py -> build/bdist.linux-
x86_64/dumb/usr/local/lib/python2.7/dist-packages/simpyple
byte-compiling build/bdist.linux-x86_64/dumb/usr/local/lib/python2.7/dist-
packages/simpyple/schedule.py to schedule.pyc
byte-compiling build/bdist.linux-x86_64/dumb/usr/local/lib/python2.7/dist-
packages/simpyple/__init__.py to __init__.pyc
running install_egg_info
Copying simpyple.egg-info to build/bdist.linux-
x86_64/dumb/usr/local/lib/python2.7/dist-packages/simpyple-0.1.2.egg-info
running install_scripts
creating /home/eriol/tmp/simpyple/dist
Creating tar archive
removing 'build/bdist.linux-x86_64/dumb' (and everything under it)
(Scusa il wordwrap, ma il log penso renda l'idea).
Trovi informazioni dettagliate sulla cosa qui:
http://docs.python.org/2/distutils/setupscript.html
Forse ti conviene utilizzare un layout più convenzionale sia per evitare
sorprese del genere, ma anche per seguire il POLA, in effetti pure non ho
notato a colpo d'occhio che il package si trovava allo stesso livello di
setup.py.
È vero, avere il repository col path del package
simpyple/simpyple/__init__.py
...
setup.py
può non sembrare il massimo, ed anche a me ogni tanto viene da pensarci, ma
poi mi dico che non vale la pena complicarsi la vita.
Ah, magari vuoi impostare il tuo editor in modo che rimuova i trailing space:
ci sono un paio di righe nel setup.py che contengono solo uno spazio... per
fortuna nel mio vimrc non uso uso l'impostazione "mostrami le lacrime di
sangue al posto dei trailing space" come usa(va) fare Marco Beri! ;-)
HTH,
--
Daniele Tricoli 'Eriol'
http://mornie.org
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Django pycharm e virtualenv
On 15/02/2014 18:03, Gollum1 wrote: Ciao lista, Ho finito di leggere il libro di Marco su Django, ora comincia il momento della rilettura e della sperimentazione effettiva. La prima cosa che sto sperimentando è virtualenv. E dopo diversi tentativi sono riuscito a creare il mio ambiente virtuale con Python 3 come base. Con pip ho installato django all'ultima versione (mentre in Debian stable c'è una versione più vecchia). Se non ho capito male, viene copiato l'eseguibile dell'installazione che ho sulla macchina, ma i packages (a parte quelli che installo esplicitamente) sono quelli del sistema linkati, oppure vengono copiati anche loro? Cosa avviene quando sul sistema viene aggiornato Python? Presumo che l'eseguibile nell'ambiente virtuale rimanga lo stesso, e anche i packages se non sono linkati, quindi non dovrebbero esserci problemi... È comunque possibile aggiornare anche la versione di Python virtualizzata? Virtualenv, e ti consiglio anche virtualenvwrapper, dovrebbe gestire tutto in questo modo: quando richiami un'applicazione, questa viene cercata prima dentro il tuo env; se non viene trovata, viene cercata nel sistema "host". Questo ti permette di avere un ambiente di lavoro quasi indipendente. Indispensabile $ pip freeze > requirements.txt che ti fa l'elenco dei pacchetti installati nel tuo env e successivamente di creare un nuovo env (magari su un'altra macchina) con il comando $ pip install -r requirements.txt Di virtualenvwrapper hanno parlato qualche tempo fa in questa lista. Ho notato che pycharm mi permette di gestire nel progetto anche l'uso di questi ambienti virtualizzati, ma la versione community, pur vedendo il package di django, non mi permette di creare un progetto esplicitamente django. Qualcuno di voi ha provato ad usare la versione community per gestire comunque un progetto django (creato quindi a priori da linea di comando)? Io sto usando la versione community.. quello che faccio e' configurare l'interprete giusto: nel mio caso e' quello dentro un virtualenv, poi lui si becca tutte le librerie ed i pacchetti installati. Per i comandi django, vai di shell; i template li gestisce abbastanza bene; javascript no.. comunque non ci ho perso tanto tempo. Ciao ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] setup bdist ==> error: can't copy 'ANIFEST.in': doesn't exist or not a regular file
2014-02-14 22:47 GMT+01:00 Piergiuliano Bossi : > error: can't copy 'ANIFEST.in': doesn't exist or not a regular file A naso pero' error: can't copy 'ANIFEST.in': doesn't exist or not a regular file ANIFEST? Non e' che manca una M all'inizio da qualche parte? Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] setup bdist ==> error: can't copy 'ANIFEST.in': doesn't exist or not a regular file
2014-02-14 22:47 GMT+01:00 Piergiuliano Bossi : > Cosa sto sbagliando? Professione? Meglio dedicarmi alle pizze? Guarda se kl amettiamo sul guadagnare di piu' ti dico che io da tempo sogno di mettermi a fare il piadinaro, pero' sai com'e', come dice il detto: "Si e' vero, sono un informatico, ma e' sempre meglio che lavorare". ;) Mi spiace solo di non essere in grado di aiutarti per la cosa, pero'. La cosa inteso come la libreria, non le pizze. Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
