Re: [Python] [Staff] start up python
Ciao Emanuele, Il 04 marzo 2014 23:34, Emanuele Barese tidus...@hotmail.com ha scritto:: scusami se ti rispondo ora ti ringrazio per la tua risposta celere. YW :: Ora riesco ad accedere senza problemi colgo l'occasione per chiederti una piccola informazione per chi come me è alle prime armi e non sa niente di programmazione può approcciare a Python ? Certo che si`. :: Se la risposta è si per neofita come me che libro potete consigliare ? Qui lascio la palla alla ML :P HTH, ciao, © -- :THE BEER-WARE LICENSE (Revision 42): ``miron AT python.it`` wrote this mail. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return. -- Carlo Miron ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
Direi che la cosa migliore è creare una tabella di anagrafica degli utenti collegata con una relazione uno-molti a una tabella per gestire gli ingressi e a una per le uscite. ciao, Cristian Il giorno mer, 05/03/2014 alle 12.16 +0100, Perini Matteo ha scritto: Ciao a tutti, dopo un po' di stallo riprendo la questione db con nuove domande. Prescindendo dal tipo di db scelto Dovrei usare il db per immagazzinare tutte le info degli utenti, e fin qui non ci sono problemi. Ad ogni utente è assegnato un codice (ID) contenuto in una tessera con chip RFID. Ad ogni ingresso/uscita gli utenti devono passare la tessera su un lettore e in quel momento la data e l'ora devono essere immagazzinate da qualche parte nel db. Forse è una domanda stupida ma come è meglio creare la struttura della tabella per ottenere lo scopo? Ad es: ID | Nome | Cognome | Data e Ora | segni particolari | Ecc.. e ogni volta che viene strisciata la tessera vado a fare un append al campo Data e Ora dell'utente? Può essere corretto? Meglio separare ingresso e uscita? tipo cosi: ID | Nome | Cognome | Data e Ora Ingresso | Data e Ora uscita | E' dentro? | segni particolari | Ecc.. Ci sono altri modi? Ad esempio per sapere il tempo di permanenza di un utente dovrei fare le differenze tra tempi di ingresso e uscita ma devo prevedere che una persona dimentichi di strisciare in ingresso o in uscita... e le cose si complicano. Avete consigli? Grazie Matteo ___ 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] FW: [Staff] start up python
2014-03-04 11:57 GMT+00:00 Daniele Palmese pal...@gmail.com: Scherzo ovviamente ed hai ragione su tutto. Però sai i santi sono i santi e quella lettura per molti aspetti mi ha segnato la vita di Pythonista. Tutti quelli che hanno scritto più di 10 righe di codice, sanno che alcuni argomenti trattati sono a dir poco antichi, su questo siamo tutti d'accordo. Il problema e' che chi non conosce Python (ovvero il target di quel libro), *non* conosce Python. Di conseguenza, non sa quello che e' cambiato, anche in modo strutturale, nello scrivere codice. Anche se ritengo che le tue puntualizzazioni siano assolutamente giuste e corrette, credo che una lettura in più arricchisca sempre il lettore, ed in questo, per alcuni aspetti, potrebbe essere utile anche solo per vedere l'evoluzione fatta dal linguaggio nel corso del tempo. Una lettura in generale fa bene. Non metto in dubbio che una prospettiva storica sul linguaggio possa aiutare, ma e' qualcosa che viene dopo. Per fare un paragone, e' chiaro che avere presente come scriveva Chaucer sia interessante e che sia addirittura fondamentale per uno studioso di letteratura inglese, pero' se uno vuole imparare a parlare inglese oggi gli consiglierei comunque di imparare a parlare l'inglese di oggi, per quanto per rimorchiare in un pub parlare come nel 1300 possa essere un tentativo degno di rispetto. Diciamo che e' non necessariamente per fare un colloquio o leggere un libro di Python moderno. Detto questo, Dive into Python e' veramente un libro di base: non e' qualcosa che leggi quando sei gia' capace. Se hai tempo di leggere un altro libro su Python, conviene che sia qualcosa di piu' sostanzioso o con una prospettiva diversa. Come per esempio il Python Cookbook [l'edizione per Py3 non la conosco, ma quella prima l'ho consumata -- e ho pure un paio di capitoli di quando era in bozza che conservo gelosamente -- posso dire che quel libro ha avuto una parte immensa nell'insegnarmi Python, lui e il Nutshell -- che ovviamente non consiglio piu' perche' si ferma a cenni sulla 2.5, sebbene, quello si, sia un libro che vale tutt'ora la pena di leggere ] P.S. Vista la tua notevole preparazione Enrico, ti esorto a darci una mano su Python.it, sono di grande aiuto persone serie e preparate come te. Avere il tempo... se ne puo' parlare, comunque. ;) -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] FW: [Staff] start up python
On 03/04/2014 05:02 PM, Strap wrote: Ciao, ti segnalo anche questo, che sara' disponibile entro due o tre giorni:http://www.amazon.it/Programmare-con-Python-Guida-completa/dp/8868950243/ E' in lingua italiana, su Python 3, aggiornato a Python 3.4. Ciao, Ma... si puo` avere un'anteprima della Tabella dei contenuti per favore? Dall'immagine della copertina e dal numero di pagine sembra che ci sia tanta ciccia:) Ciao, l'indice dei contenuti e una descrizione saranno disponibili su Amazon tra qualche giorno. In ogni caso, ecco una breve TOC: * introduzione al linguaggio e alla libreria standard * il core data type, con un occhio di riguardo allo standard Unicode e alla codifica delle stringhe * funzioni, generatori, coroutine, file, wildcard ed espressioni regolari * moduli e package, scope e namespace, ambienti virtuali, installazione e distribuzione delle applicazioni, docstring validation testing * classi, ereditarietà, gestione delle eccezioni, property e decoratori * modello ad oggetti, attributi magici, descriptor, metaclassi e test driven development Ciao, Marco -- Marco Buttu INAF-Osservatorio Astronomico di Cagliari Via della Scienza n. 5, 09047 Selargius (CA) Phone: 070 711 80 217 Email: mbu...@oa-cagliari.inaf.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] FW: [Staff] start up python
On 03/04/2014 11:20 PM, Gollum1 wrote: Il 04 marzo 2014 13:12, Marco Buttu http://www.amazon.it/Programmare-con-Python-Guida-completa/dp/8868950243/ E' in lingua italiana, su Python 3, aggiornato a Python 3.4. Ciao, Marco Interessante, esiste anche in formate elettronico (preferibilmente epub)? per ora su Amazon non è ancora disponibile. L'editore mi ha detto che sara' disponibile in formato elettronico tra due settimane circa, ma per il momento non ti so dire altro :/ Ciao, Marco -- Marco Buttu INAF-Osservatorio Astronomico di Cagliari Via della Scienza n. 5, 09047 Selargius (CA) Phone: 070 711 80 217 Email: mbu...@oa-cagliari.inaf.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] FW: [Staff] start up python
Il 04/03/2014 13:12, Marco Buttu ha scritto: Ciao, ti segnalo anche questo, che sara' disponibile entro due o tre giorni: http://www.amazon.it/Programmare-con-Python-Guida-completa/dp/8868950243/ E' in lingua italiana, su Python 3, aggiornato a Python 3.4. Ciao, Marco Grazie! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] FW: [Staff] start up python
Ciao Emanuele, Python e' un ottimo linguaggio di programmazione per iniziare... non ti servono altre basi. Di documentazione online ce n'e' a bizzeffe. Magari puoi cominciare con un tutorial interattivo: http://www.learnpython.org/ saluti, -Francesco 2014-03-04 11:24 GMT+01:00 Emanuele Barese tidus...@hotmail.com: Ciao a tutti scusatemi se sarò diretto, ma vorrei imparare questo linguaggio di programmazione, per poter usare anche io python dovrei avere basi di altri linguaggi di programmazione ? Ho dato un'occhiata alla sezione http://www.python.it/doc/newbie/ vi volevo chiedere per poter iniziare ad usare python quale libro potrei usare prima ? ero propenso nell'acquistare http://www.amazon.it/Python-Marco-Beri/dp/8850329156/ref=sr_1_1?s=booksie=UTF8qid=1393889718sr=1-1keywords=pythonma l'ho visto molto piccolo per start up che libro o guida potrei usufruire ? Distinti saluti ___ 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] info su db
On 2014-03-05 11:16, Perini Matteo wrote: Ciao a tutti, dopo un po' di stallo riprendo la questione db con nuove domande. Prescindendo dal tipo di db scelto Dovrei usare il db per immagazzinare tutte le info degli utenti, e fin qui non ci sono problemi. Ad ogni utente è assegnato un codice (ID) contenuto in una tessera con chip RFID. Ad ogni ingresso/uscita gli utenti devono passare la tessera su un lettore e in quel momento la data e l'ora devono essere immagazzinate da qualche parte nel db. Forse è una domanda stupida ma come è meglio creare la struttura della tabella per ottenere lo scopo? Ad es: ID | Nome | Cognome | Data e Ora | segni particolari | Ecc.. e ogni volta che viene strisciata la tessera vado a fare un append al campo Data e Ora dell'utente? Può essere corretto? Meglio separare ingresso e uscita? tipo cosi: ID | Nome | Cognome | Data e Ora Ingresso | Data e Ora uscita | E' dentro? | segni particolari | Ecc.. Dovresti studiare qualcosa di molto elementare sui database: non puoi replicare informazioni su nome e cognome ad ogni strisciata, altrimenti è un log non relazionale, tanto vale tu lo scriva in un file. Le informazioni sugli utenti e le strisciate devono essere in due tabelle diverse. Separare nome è cognome è un'idea regolare, ma un po' limitata (ho sempre l'esempio del mio collega che non ha il cognome). Avere sia data ingresso che data uscita nello stesso record è giustissima: se un record rappresenta un periodo devono essere riportati sia inizio che fine, usare il record di prima come inizio porta a complicazioni terribili. L'informazione è dentro può essere dedotta dal fatto che una presenza abbia la data uscita nulla. Peraltro un utente non è collegato ad una lettura: un tag lo è, quindi secondo me dovresti avere come minimo: Utente: id, nome, cognome, indirizzo ecc.. Tag: id (del db, forse non necessario), identificativo (quello che il lettore legge), emesso il, ritirato il, motivo del ritiro ecc. Utente per tag: quale utente, quale tag, da quando l'ha avuto, fino a quando l'ha avuto. Lettura: id, quale tag, quale lettore, a che ora. Presenza: id lettura in, id lettura out. Lettore: id, ...tutte le informazioni che servono Nota che una lettura è un evento imprescindibile: quella cosa è successa. Una presenza è una policy: mette in relazione due letture nel caso più normale ma potrebbero succedere cose strane: tipo uno che entra ed esce in modo imprevisto (in barella? o semplicemente il lettore era rotto?) per cui mi sembra giusto separare le Letture (da registrare) dalle Presenze (da ricostruire). Potresti anche avere quello che entra, passa il tag a quello dietro e quello entra anche lui: è vietato da una policy, non dalla fisica. -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
Il 05/03/2014 17:21, Daniele Varrazzo ha scritto: Dovresti studiare qualcosa di molto elementare sui database: non puoi replicare informazioni su nome e cognome ad ogni strisciata, altrimenti è un log non relazionale, tanto vale tu lo scriva in un file. Le informazioni sugli utenti e le strisciate devono essere in due tabelle diverse. Separare nome è cognome è un'idea regolare, ma un po' limitata (ho sempre l'esempio del mio collega che non ha il cognome). Avere sia data ingresso che data uscita nello stesso record è giustissima: se un record rappresenta un periodo devono essere riportati sia inizio che fine, usare il record di prima come inizio porta a complicazioni terribili. L'informazione è dentro può essere dedotta dal fatto che una presenza abbia la data uscita nulla. Peraltro un utente non è collegato ad una lettura: un tag lo è, quindi secondo me dovresti avere come minimo: Utente: id, nome, cognome, indirizzo ecc.. Tag: id (del db, forse non necessario), identificativo (quello che il lettore legge), emesso il, ritirato il, motivo del ritiro ecc. Utente per tag: quale utente, quale tag, da quando l'ha avuto, fino a quando l'ha avuto. Lettura: id, quale tag, quale lettore, a che ora. Presenza: id lettura in, id lettura out. Lettore: id, ...tutte le informazioni che servono Nota che una lettura è un evento imprescindibile: quella cosa è successa. Una presenza è una policy: mette in relazione due letture nel caso più normale ma potrebbero succedere cose strane: tipo uno che entra ed esce in modo imprevisto (in barella? o semplicemente il lettore era rotto?) per cui mi sembra giusto separare le Letture (da registrare) dalle Presenze (da ricostruire). Potresti anche avere quello che entra, passa il tag a quello dietro e quello entra anche lui: è vietato da una policy, non dalla fisica Grazie a tutti delle risposte, non ho risposto subito perché ho passato il pomeriggio a studiare ;) Ho capito che devo fare svariate tabelle collegate tra loro e che contengano tutti i dati. Intanto farò qualche prova poi ritornerò con le domande. Ciao Matteo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-05 16:21 GMT+00:00 Daniele Varrazzo p...@develer.com: Separare nome è cognome è un'idea regolare, ma un po' limitata (ho sempre l'esempio del mio collega che non ha il cognome). Interessante... non ci avevo effettivamente pensato. Piu' ci sono tutte le magagne su middle name (che da noi e' poco comune) et similia. Avere sia data ingresso che data uscita nello stesso record è giustissima: se un record rappresenta un periodo devono essere riportati sia inizio che fine, usare il record di prima come inizio porta a complicazioni terribili. +1 Utente: id, nome, cognome, indirizzo ecc.. Tag: id (del db, forse non necessario), identificativo (quello che il lettore legge), emesso il, ritirato il, motivo del ritiro ecc. Utente per tag: quale utente, quale tag, da quando l'ha avuto, fino a quando l'ha avuto. Lettura: id, quale tag, quale lettore, a che ora. Presenza: id lettura in, id lettura out. Lettore: id, ...tutte le informazioni che servono Io andrei piano con tutti questi id. Quando c'e' un ID naturale, niente da dire (e.g., employee id). Pero' mettere gli ID per non usare chiavi primarie vere, non mi piace tanto. Tipicamente un evento di lettura e' verosimilmente identificato univocamente da utente, ora, verosimilmente quale lettore lo ha fatto. Nota che una lettura è un evento imprescindibile: quella cosa è successa. Una presenza è una policy: mette in relazione due letture nel caso più normale ma potrebbero succedere cose strane: tipo uno che entra ed esce in modo imprevisto (in barella? o semplicemente il lettore era rotto?) per cui mi sembra giusto separare le Letture (da registrare) dalle Presenze (da ricostruire). Potresti anche avere quello che entra, passa il tag a quello dietro e quello entra anche lui: è vietato da una policy, non dalla fisica. +1 Inoltre, a meno che non abbiano policy molto strette, si scazzeranno sempre le cose. Tipo in un dc tenuto bene ti vengono a prendere se sei nella stanza sbagliata perche' hai tailato o hai chiuso una porta senza passarla. Ma se questo non avviene, ti trovi con un maciello. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] FW: [Staff] start up python
Il giorno Tue, 4 Mar 2014 11:24:47 +0100 Emanuele Barese tidus...@hotmail.com ha scritto: http://www.amazon.it/Python-Marco-Beri/dp/8850329156/ref=sr_1_1?s=booksie=UTF8qid=1393889718sr=1-1keywords=python ma l'ho visto molto piccolo per start up che libro o guida potrei ho provato a scaricare la versione Kindle che avrei usato su un PC win. Ma avendo a casa linux e non essendoci la versione kindle linux, amazon mi ha fatto storie. Allora ho fatto partire win in vbox , ho installato kindle e poi scaricato Ora vorrei capire dove mi ha installato il file relativo per copiarlo sul pc dove vorrei leggerlo. ho fatto un search *.mobi ma non trovo nulla. Qualcuno mi sa dire in che cartella di win7 lo trovo? grazie -- Filippo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
On 2014-03-05 17:05, enrico franchi wrote: 2014-03-05 16:21 GMT+00:00 Daniele Varrazzo p...@develer.com: Utente: id, nome, cognome, indirizzo ecc.. Tag: id (del db, forse non necessario), identificativo (quello che il lettore legge), emesso il, ritirato il, motivo del ritiro ecc. Utente per tag: quale utente, quale tag, da quando l'ha avuto, fino a quando l'ha avuto. Lettura: id, quale tag, quale lettore, a che ora. Presenza: id lettura in, id lettura out. Lettore: id, ...tutte le informazioni che servono Io andrei piano con tutti questi id. Quando c'e' un ID naturale, niente da dire (e.g., employee id). Pero' mettere gli ID per non usare chiavi primarie vere, non mi piace tanto. Tipicamente un evento di lettura e' verosimilmente identificato univocamente da utente, ora, verosimilmente quale lettore lo ha fatto. Questa guerra di religione è probabilmente più vecchia sia di Emacs che di Vi :) La penso come te: se vedi nei miei esempi ho dato un forse a mettere l'id su un tag. Non conosco la tecnologia, ma probabilmente l'identificativo pubblico è sufficiente. Ma il resto no: la tupla (id tag, id lettore, timestamp) non è pratica come chiave di una Lettura. Hai già bisogno di 6 campi per linkare due letture ad una Presenza, in più un timestamp è (praticamente) un valore reale, non discreto, e si presta male come identificativo (magari in postgres ha un numero di usec intero, poi passa attraverso python che lo converte in virgola mobile, fai una seconda query e ci scappa un arrotondamento di un milionesimo di secondo che te lo fa mancare). Sono favorevoli alle chiavi naturali, ma quando siano *veramente* univoche. Il che è più raro di quello che sembra. Una targa non identifica abbastanza bene un'auto (come feci in uno dei primi programmi che scrissi, e i venditori si sovrascrivevano a vicenda le auto da rendere nei preventivi, perché quando il cliente non ricordava a memoria la targa scrivevano tutti NON...). Non sono neanche univoche, come sanno quelli con targa CD ... .. che beccano le multe al posto di quelli del Corpo Diplomatico (che sono uguali ma scritte in blu...). Un codice fiscale non identifica abbastanza bene una persona: puoi non conoscerlo, può non averlo... Allo stesso modo sono favorevole alle chiavi multiple, ma quando siano pratiche: in una tabella di unione molti-a-molti non ho problemi ad usare la coppia di pkey come pkey, ma non butto il sangue a cercarne una quando non è ovvia. Chiavi naturali/surrogate e chiavi singole/multiple sono battaglie già combattute e di cui si sa che non c'è vincitore. Che ne dici di una bella partita a scacchi? :) -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
On 5 Mar 2014 19:46, Daniele Varrazzo p...@develer.com wrote: Chiavi naturali/surrogate e chiavi singole/multiple sono battaglie già combattute e di cui si sa che non c'è vincitore. +1 Che ne dici di una bella partita a scacchi? :) Da finire rigorosamente in stallo :-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-05 12:31 GMT+01:00 Cristian Di Stefano cristian.distef...@isprambiente.it: Direi che la cosa migliore è creare una tabella di anagrafica degli utenti collegata con una relazione uno-molti a una tabella per gestire gli ingressi e a una per le uscite. +1 Carlos -- Coloro che sognano di giorno sono uomini pericolosi, perche' sono capaci di recitare a occhi aperti il loro sogno fino a renderlo possibile. Ed e' questo che feci anch'io. - (T.E. Lawrence) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
