Re: [Python] Errore di semantica -
On Jun 24, 2015 8:49 AM, "Daniele Zambelli" wrote: > La matematica non credo, ma forse la fisica potrebbe aiutare. Daniele, hai ragione, ma per evitare anche questo problema le uscite della roulette sono monitorate costantemente e non appena viene notato uno scostamento da una normale distribuzione statistica (da un programma ovviamente) la roulette viene fatta controllare e ritirare. C'è una storia su come sono state cambiate le regole del black jack per non favorire i giocatori che è molto istruttiva, ma sarei troppo OT. Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Errore di semantica -
On Jun 24, 2015 8:50 AM, "Marco Beri" wrote: > > > On Jun 24, 2015 8:28 AM, "Simone Federici" wrote: > > > > Marco Baro: Rotfl! Solo ora ho visto... ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Errore di semantica -
On Jun 24, 2015 8:28 AM, "Simone Federici" wrote: > > Marco Baro: > >> Ma se pensi che la roulette sia "battibile" con un qualsiasi sistema, rinuncia: la matematica ti condanna alla sconfitta. Per poter vincere dovresti avere capitale infinito e puntate non limitate. Cose false entrambe. > > Tieni per te le tue paure, ma condividi con gli altri il tuo coraggio. > (Robert Louis Stevenson) Queste non sono paure (vado ancora al casinò una volta l'anno) ma è semplice conoscenza. Tra l'altro è conoscenza "cassandresca" nel senso che l'avrò detto cento volte ma nessuno mai mi ha ascoltato. L'illusione di poter battere il banco è dura a morire. Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Errore di semantica -
Il 24 giugno 2015 08:21, Marco Beri ha scritto: > Ma se pensi che la roulette sia "battibile" con un qualsiasi sistema, > rinuncia: la matematica ti condanna alla sconfitta. Per poter vincere > dovresti avere capitale infinito e puntate non limitate. Cose false > entrambe. Odio il gioco d'azzardo. Io a naso punterei sui numeri che escono più spesso piuttosto che sui ritardatari. La matematica non credo, ma forse la fisica potrebbe aiutare. Un sorriso. -- 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
[Python] Errore di semantica -
Marco Baro: > Ma se pensi che la roulette sia "battibile" con un qualsiasi sistema, > rinuncia: la matematica ti condanna alla sconfitta. Per poter vincere > dovresti avere capitale infinito e puntate non limitate. Cose false > entrambe. > Tieni per te le tue paure, ma condividi con gli altri il tuo coraggio. (Robert Louis Stevenson) -- Simone Federici Software Craftsman XP, Agile, Scrum, Kanban Quality, performance & security Explicit is better than implicit. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Errore di semantica -
On Jun 24, 2015 2:41 AM, "Alessandro Re" wrote: > E non solo ti dirò dove sbagli per l'errore che descrivi, ma per gli > altri mille peccati capitali che hai commesso nel codice >:D ahahah Aggiungo un commento anche io, ma solo perché da giovane mi sono illuso fino a che ho studiato un po' più seriamente la questione. Se stai scrivendo questo programma per diletto vai pure avanti e divertiti. Ma se pensi che la roulette sia "battibile" con un qualsiasi sistema, rinuncia: la matematica ti condanna alla sconfitta. Per poter vincere dovresti avere capitale infinito e puntate non limitate. Cose false entrambe. Ciao. Marco. P.s. Oltre al fatto che è vietato usare un computer al casinò. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Errore di semantica -
2015-06-24 0:19 GMT+01:00 Carpediem :
> Ho seguito i passaggi uno ad uno anche con carta e penna, ho modificato il
> codice più volte ma alla fine ottengo sempre lo stesso non voluto
> risultato. Mi aiutate a capire?
Ciao, ti dirò dove secondo me stai sbagliando, anche se non conosco la roulette.
E non solo ti dirò dove sbagli per l'errore che descrivi, ma per gli
altri mille peccati capitali che hai commesso nel codice >:D ahahah
> uscita_passe = 0
> uscita_manque = 0
> scommessa_semplice = ("passe","manque")
> scommessa_passe = 0
> scommessa_manque = 0
> tutti_i_numeri =
> (0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24!
> ,25,26,27,28,29,30,31,32,33,34,35,36)
Se la roulette avesse avuto 1 numeri cosa facevi, li elencavi uno
per uno? :P
Usa tuple(range(37)) anziché quell'elenco che hai scrtto.
> passe = (19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36)
> manque = (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18)
Per questi usa tuple(range(19, 37)) e tuple(range(1, 19)).
> liste_in_ritardo = []
> puntate_possibili = ("passe","manque","pari","dispari","nero","rosso","prima
> dozzina","seconda dozzina","terza dozzina","prima colonna","seconda
> colonna","terza colonna","prima sestina","seconda sestina","terz
> a sestina","quarta sestina","quinta sestina","sesta sestina",\
> "settima sestina","ottava sestina","nona
> sestina","decima sestina","undicesima sestina","quattro primi","carre
> 1a5","carre 2a6","carre 4a8","carre 5a9","carre 7a11","carre 8a12","carre
> 10a14","carre 11a15","carre 13a17","carre 14a18","carre 16a20","carre
> 17a21",\
> "carre 19a23","carre 20a24","carre 22a26","carre
> 23a27","carre 25a29","carre 26a30","carre 28a32","carre 29a33","carre
> 31a35","carre 32a36")
Questa sfilza di stringhe potresti formattarla meglio, come ad esempio
puntate_possibili = (
"passe",
"manque",
"pari",
"dispari",
"nero",
"rosso",
"prima
ecc, anche se esce una cosa lunghissima, personalmente preferisco un
codice più lungo e leggibile che di qualche riga in meno e che mi fa
incrociare gli occhi.
> print("Attenzione: stiamo facendo riferimento alle regole della Roulette
> francese.")
> print("Si presuppone, come previsto ad esempio al Casino' di Venezia, che la
> puntata minima accettata \nsia di 10 Euro e la massima di 600. Si ritiene
> scontato, inoltre, che il giocatore\nsegua rigorosamente i suggerimenti che
> verranno evidenziati dal programma.")
> print()
Ho notato che usi un sacco di print(); non voglio dirti che è una cosa
brutta, ma personalmente non mi piace mischiare gli stili: o usi una
print per ogni riga, o usi \n in una print sola. Io andrei di una
print per ogni riga. Ti consiglio, molto umilmente, di adottare uno
stile ed essere coerente ad esso.
> capitale_disponibile = eval(input("Per cominciare, indicami l'importo che
> intendi mettere a disposizione per il gioco (si consiglia almeno 2500 Euro)"
> ))
eval(input()) è una cosa che vuoi evitare quasi sempre. Non usarlo.
Usa int(input()) se vuoi ottenere un intero oppure usa usa
ast.literal_eval(input()).
https://docs.python.org/3/library/ast.html#ast.literal_eval
> print("Giocata"+((" ")*17),"ritardi di uscita"+((" ")*6),"Giocata"+(("
> ")*17),"ritardi di uscita"+((" ")*8))
Esistono opzioni migliori per formattare "incolonnando". Esempio:
print('Valore: {:12} Valore {:8}'.format(4, 123))
Usa format() e tutte le sue belle opzionI:
https://docs.python.org/3.3/library/string.html#formatstrings
> if numero_uscito in passe:
Se passe e manque e tutti_i_numeri li usi solo per tenere elenchi di
numeri, puoi fare 2 cose per migliorare il tuo codice:
1. usare set() anziché tuple(). Set è molto più veloce per vedere se
un elemento è al suo interno, rispetto a tuple, e la sintassi "valore
in insieme" è invariata e molto gradevole da leggere. Quindi, anziché
usare tuple(range(37)), usa set(range(37)). Se, invece, la tupla ti
serve perché è ordinata (set non preserva l'ordine), allora tieni la
tupla.
2. Se hai degli intervalli numerici e devi verificare se sei in tali
intervalli, non usare né tuple né set. Usa gli operatori <=, e magari
definisci un paio di funzioni per leggere meglio:
def in_passe(n):
return 19 <= n <= 36
if in_passe(numero_uscito):
etc
> uscita_manque =+1
E questa riga credo sia l'origine del tuo baco. Più volte nel codice scrivi
variabile =+1
e secondo me tu stai cercando di ottenere
variabile = variabile + 1
ma forse non sai, o non ti sei accorto, che l'operatore += è ben
diverso dai due operatori =+.
a += b vuol dire a = a + b
a =+ b vuol dire a = (+b) cioé a = b (+ indica il segno del numero).
> prosegui_gioco = input("Vuoi continuare a giocare? si/no ")
> if prosegui_gioco == "si":
ultimo appunto: in genere è buona cosa fare controllo indipendenti
dalle maiuscole e dalle minuscole.
Quindi:
prosegui_gioco = input('Blah").lower()
così se l'utente inserisce SI o Si, il
[Python] Errore di semantica -
Scusate ma ci sto sbattendo la testa da 5 giorni e non riesco a capire dov'è
che sbaglio. Sto testando queste poche righe di codice e
quando il programma mi chiede quale sia il numero uscito, scrivo 19 e
proseguendo, nella schermata di riepilogo successiva mi ritrovo,
così come mi aspetto, che il ritardo di uscita manque sia incrementato di 1.
Potete dirmi per cortesia, per quale diavolo di errore
ripetendo l'inserimento sempre dello stesso numero, nella schermata di
riepilogo successiva invece di ritrovarmi con il ritardo di uscita
manque a 2 me lo ritrovo fermo a 1?
Ho seguito i passaggi uno ad uno anche con carta e penna, ho modificato il
codice più volte ma alla fine ottengo sempre lo stesso non voluto
risultato. Mi aiutate a capire?
Grazie
uscita_passe =0
uscita_manque =0
scommessa_semplice = ("passe","manque")
scommessa_passe =0
scommessa_manque =0
tutti_i_numeri =
(0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36)
passe = (19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36)
manque = (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18)
liste_in_ritardo = []
puntate_possibili = ("passe","manque","pari","dispari","nero","rosso","prima dozzina","seconda dozzina","terza dozzina","prima colonna","seconda
colonna","terza colonna","prima sestina","seconda sestina","terza sestina","quarta sestina","quinta sestina","sesta sestina",\
"settima sestina","ottava sestina","nona sestina","decima sestina","undicesima sestina","quattro primi","carre 1a5","carre 2a6","carre
4a8","carre 5a9","carre 7a11","carre 8a12","carre 10a14","carre 11a15","carre 13a17","carre 14a18","carre 16a20","carre 17a21",\
"carre 19a23","carre 20a24","carre 22a26","carre 23a27","carre 25a29","carre 26a30","carre
28a32","carre 29a33","carre 31a35","carre 32a36")
print("Attenzione: stiamo facendo riferimento alle regole della Roulette
francese.")
print("Si presuppone, come previsto ad esempio al Casino' di Venezia, che la puntata
minima accettata\nsia di 10 Euro e la massima di 600. Si ritiene scontato, inoltre, che
il giocatore\nsegua rigorosamente i suggerimenti che verranno evidenziati dal
programma.")
print()
capitale_disponibile =eval(input("Per cominciare, indicami l'importo che intendi
mettere a disposizione per il gioco (si consiglia almeno 2500 Euro)"))
print()
inizio_gioco =0
giocate_effettuate =0
whileinizio_gioco ==0:
print("A seguire, l'elenco delle puntate possibili considerate da questo
programma e l'attuale situazione del gioco:")
print()
print("Giocata"+(("")*17),"ritardi di uscita"+(("")*6),"Giocata"+(("")*17),"ritardi di
uscita"+(("")*8))
print("\npasse"+(("")*27),uscita_passe,(("")*13),"manque"+(("")*26),uscita_manque)
print()
iflen(liste_in_ritardo) ==0:
print("Al momento non ho scommesse da suggerirti: salta la mano e")
eliflen(liste_in_ritardo) >0:
ifuscita_manque >=8:
print("I numeri da 1 a 18 (manque) sono in ritardo
da",uscita_manque,"estrazioni")
elifuscita_passe >=8:
print("I numeri da 19 a 36 (passe) sono in ritardo da",
uscita_passe,"estrazioni")
controllo_numero_uscito =0
whilecontrollo_numero_uscito ==0:
numero_uscito =eval(input("indica il numero uscito"))
print()
ifnumero_uscitonot intutti_i_numeri:
print("Devi inserire un numero compreso tra 0 e 36")
elifnumero_uscitointutti_i_numeri:
conferma_numero_uscito =input("Sei sicuro di aver inserito il numero
giusto? si/no")
print()
ifconferma_numero_uscito =="no":
print()
elifconferma_numero_uscito =="si":
controllo_numero_uscito =+1
else:
print("Per confermare o smentire devi scrivere si o no")
ifnumero_uscitoinpasse:
uscita_passe =0
uscita_manque =+1
print()
print("E' appena uscito un numero del gruppo passe,",)
ifuscita_passeinliste_in_ritardo:
delliste_in_ritardo[uscita_passe]
ifuscita_manque ==8:
liste_in_ritardo.append(uscita_manque)
elifnumero_uscitoinmanque:
uscita_manque =0
uscita_passe =+1
print()
print("E' appena uscito un numero del gruppo manque,",)
ifuscita_manqueinliste_in_ritardo:
delliste_in_ritardo[uscita_manque]
ifuscita_passe ==8:
liste_in_ritardo.append(uscita_passe)
controllo_prosegui_gioco =0
whilecontrollo_prosegui_gioco ==0:
prosegui_gioco =input("Vuoi continuare a giocare? si/no")
ifprosegui_gioco =="si":
print()
controllo_prosegui_gioco =+1
giocate_effettuate =+1
elifprosegui_gioco =="no":
inizio_gioco =+1
print("Ok, spero tu ti sia divertito; arrivederci")
controllo_prosegui_gioco =+1
else:
print("Devi rispondere si o no")
_
Re: [Python] Stop using print for debugging
Roberto Polli: > > Per ogni chiamata che necessita la lambda-join-proxy ce ne sono almeno > 100 semplici...ad ogni modo se vogliamo > sviluppare una nuova libreria io sono d'accordo eh :DDD c'è spazio per le proposte, buttati :-) -- Simone Federici Software Craftsman XP, Agile, Scrum, Kanban Quality, performance & security Explicit is better than implicit. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Stop using print for debugging
Il 23 giugno 2015 21:51, Simone Federici ha scritto:
> non sarebbe male se invece si andasse in qualcosa tipo
>
> logger.debug('dump: %s', (json.dumps, (self.obj),))
> [non funziona]
> logger.debug('dump: %s', (lambda x: "\t".join("%s=%s" % (k, v) for k, v in
> x.items(), (data,)))
> [non funziona]
Il programmatore medio (tipo me) userebbe queste sintassi per generare
bug tramite il logging.
imho il logging:
- deve da esse semplice;
- facile da leggere eg in troubleshooting alle 3 di notte ;)
- a prova di errori
Una cosa sensata sarebbe migliorare la lazyness all'interno, ma
l'interfaccia non dovrebbe permettere
di fare mandrakate.
Per ogni chiamata che necessita la lambda-join-proxy ce ne sono almeno
100 semplici...ad ogni modo se vogliamo
sviluppare una nuova libreria io sono d'accordo eh :DDD
Pace,
R.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Stop using print for debugging [TDD Everywhere]
Il 23 giugno 2015 21:10, Carlos Catucci ha scritto: > ma l'errore si origina (chissa' dove) nel mio codice Anche qui un po' di TDD non è che guasta eh :P Pace, R ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Circular references Django migration problem
Carlos Catucci:
> Va beh lunedi' provo a commentare un poco di rovba fino a che non vedo
> socmparire la Circular Ref cosi da capire cosa gli dia fastidio.
>
hai provato a riscrivere il builtin __import__ in modo da stamparti
l'ordine di importazione dei moduli?
qualcosa di questo tipo da mettere nel manage.py:
import __builtin__
original_import = __builtin__.__import__
def log_import(name, globals={}, locals={}, fromlist=[], level=-1):
print name
return original_import(name, globals=globals, locals=locals,
fromlist=fromlist, level=level)
__builtin__.__import__ = log_import
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Stop using print for debugging
Enrico franchi:
> logger.debug('dump: %s', JSONDumper(something))
yep, vuol dire scrivere però struttura OOP per il logging, non che ci sia
nulla di male.
non sarebbe male se invece si andasse in qualcosa tipo
logger.debug('dump: %s', (json.dumps, (self.obj),))
[non funziona]
dove cioè il modulo logging inglobasse la logica lazy ad esempio con la
classica tupla (f, *args, **kwargs) da passare come un parametro
oppure
logger.debug('dump: %s', lambda : json.dumps(self.obj))
[non funziona]
dove logging accetta callable methods come parametri
Enrico franchi:
> Poi in Java hanno elaborato su logging con librerie crescentemente piu'
> elaborate e comode e noi siamo rimasti indietro -- nel senso che non
> conosco librerie alternative che siano largamente usate.
Si ma grosso modo sono andati verso il multithread, implementazioni più
leggere, implementazioni disparate. L'utilizzo resta lo stesso a livello
sviluppatore, e dietro puoi scegliere varie implementazioni javiste.
Enrico Bianchi:
> Da quello che ho notato, dalla comparsa di log4j, tutte le librerie per il
> logging tendono ad imitarne il comportamento, anche la libreria di logging
> presente nella libreria standard di Java (con qualche modifica). Non ho mai
> capito il perche`, presumo semplicemente che sia legato alla diffusione di
> log4j frammista alla diffusione di Java...
Secondo me il problema di log4j è la licenza, per questo sono nate delle
specifiche molto simili... (non ho nulla contro la licenza apache2 - solo
che certe situazioni scappano da tutto ciò che è open)
Marco Beri:
> Concordo. Infatti io di solito se voglio leggere un dict e proprio mi
> serve averlo nel log, ci scrivo una roba così "\t".join("%s=%s" % (k, v)
> for k, v in data.items())
questo però è il classico esempio da mettere lazy o sotto logger.
isEnabledFor(logging.DEBUG)
tipo devi scrivere un lazy_join.
sarebbe fico poter scrivere
logger.debug('dump: %s', (lambda x: "\t".join("%s=%s" % (k, v) for k, v in
x.items(), (data,)))
[non funziona]
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Stop using print for debugging
2015-06-23 21:00 GMT+02:00 Giovanni Porcari : > Scusa ma in debug non puoi servire la versione non compressa ? Sarebbe la stessa cosa. Mi darebbe lo stesso un errore su una riga di jQuery.js, ma l'errore si origina (chissa' dove) nel mio codice (sarei un idiota anche solo a pensare che sia un bug di jQuery). Carlos -- EZLN ... Para Todos Todo ... Nada para nosotros ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Stop using print for debugging
> Il giorno 23/giu/2015, alle ore 20:53, Carlos Catucci > ha scritto: > > Grazie, sono davvero ottime metodologie. Il debug e' sempre la parte rognosa. > E fortuna che python da lo stacktrace. Quando uso hjQuery e mi da errore > sulla riga 4 di jquery-min.js (ovvio che non e' li l'errrore ma in qualche > mia chiamata) e' roba da uscirci matti. > Scusa ma in debug non puoi servire la versione non compressa ? G ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Stop using print for debugging
On 06/23/2015 06:58 PM, enrico franchi wrote: Poi detto fra di noi: logging sembra essere stato pensato da Javisti. Io temo che semplicemente a suo tempo sia stata presa pesante ispirazione da logging di Java Da quello che ho notato, dalla comparsa di log4j, tutte le librerie per il logging tendono ad imitarne il comportamento, anche la libreria di logging presente nella libreria standard di Java (con qualche modifica). Non ho mai capito il perche`, presumo semplicemente che sia legato alla diffusione di log4j frammista alla diffusione di Java... e che non sia stata concepita un'interfaccia piu' Pythonica del tutto. Beh, la stdlib di Python ha parecchie idiosincrasie ;) Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Stop using print for debugging
2015-06-23 8:41 GMT+02:00 Simone Federici :
> altro suggerento per loggare elementi costosi a livello computazionale
> tipo json.dumps() è wrapparli con isEnabledFor
>
> if logger.isEnabledFor(logging.DEBUG):
> logger.debug('dump: %s', json.dumps())
>
Grazie, sono davvero ottime metodologie. Il debug e' sempre la parte
rognosa. E fortuna che python da lo stacktrace. Quando uso hjQuery e mi da
errore sulla riga 4 di jquery-min.js (ovvio che non e' li l'errrore ma in
qualche mia chiamata) e' roba da uscirci matti.
Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Stop using print for debugging
2015-06-23 19:02 GMT+02:00 enrico franchi :
>
> 2015-06-23 7:41 GMT+01:00 Simone Federici :
>
>> altro suggerento per loggare elementi costosi a livello computazionale
>> tipo json.dumps() è wrapparli con isEnabledFor
>>
>
> Ah, dimenticavo una cosa... Io *odio* JSON nei logs. E *odio* gli stack
> trace nei log. In primo luogo tendono a spaccare qualunque tipo di
> aggregazione uno voglia fare (visto che i log testuali di solito si
> processano a botte di sed/awk/grep e compagnia che non capiscono affatto
> JSON) *e* frantumano le palle in quanto normalmente sarebbe bello assumere
> una linea di log -> un record, viceversa il multilinea fracassa.
>
Concordo. Infatti io di solito se voglio leggere un dict e proprio mi serve
averlo nel log, ci scrivo una roba così "\t".join("%s=%s" % (k, v) for k, v
in data.items())
Ciao.
Marco.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Stop using print for debugging
2015-06-23 7:41 GMT+01:00 Simone Federici : > altro suggerento per loggare elementi costosi a livello computazionale > tipo json.dumps() è wrapparli con isEnabledFor > Ah, dimenticavo una cosa... Io *odio* JSON nei logs. E *odio* gli stack trace nei log. In primo luogo tendono a spaccare qualunque tipo di aggregazione uno voglia fare (visto che i log testuali di solito si processano a botte di sed/awk/grep e compagnia che non capiscono affatto JSON) *e* frantumano le palle in quanto normalmente sarebbe bello assumere una linea di log -> un record, viceversa il multilinea fracassa. In Java di solito faccio in modo tale che lo stack trace finisca su una sola riga (o quando ho tempo finisca in un file di log separato -- quando voglio correlare e' piuttosto facile farlo, ma quando voglio solo processare i log non sono d'impiccio). Se lo ho nella stessa riga posso processare tutto con 1 linea <-> un evento. Se mi interessano gli stack trace da ispezionare posso fare qualcosa tipo | tr '|' '\n' | less . -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Stop using print for debugging
2015-06-22 23:28 GMT+01:00 Enrico Bianchi : > Giusto perche` si e` detto pochi minuti fa' di aprire qualche discussione, > che ne pensate di questa? Ovvero, che ne pensate dell'usare logging al > posto di print per debuggare (parte) del codice? > > http://inventwithpython.com/blog/2012/04/06/stop-using-print-for-debugging-a-5-minute-quickstart-guide-to-pythons-logging-module/ Trovo che secondo me l'autore sia confuso sul concetto di "debug", ovvero, dovrebbe specificare all'inizio che "per tutti quelli che pensano che print sia uno strumento utile di debug (e per tutti quelli che non lo pensano nel caso generale ma in casi specifici vogliono usarlo) ... blah blah blah. Per il resto ha essenzialmente ragione: logging ti da flessibilita' sensibile e funziona bene in produzione. Print, di per se, no. Non e' chiaro dove sia connesso lo stdout su un generico sistema in produzione, se devi gestire log-rotation et similia te lo devi fare a mano, etc etc etc etc. Quindi si: se vuoi usare una linea di output per "fare debugging", in generale logging e' meglio. Se e' qualcosa che tanto va a scomparire prima del commit (e quindi e' effettivamente "vero" debugging -- tracciare l'applicazione in produzione e' una cosa complementare ma leggermente diversa) *e* sai dove e' stdout etc etc etc allora e' abbastanza ok. In particolare a me piace la proprieta' che nel codice di produzione non ho tipicamente delle print in giro, quindi e' molto facile grepparle prima di fare commit. Viceversa finisce che la linea di log inserita non per fare normale tracing ma per debuggare uno specifico problema -- che ci si auspica scompaia prima di committare -- rimanga li ad inquinare il tutto. Poi detto fra di noi: logging sembra essere stato pensato da Javisti. Io temo che semplicemente a suo tempo sia stata presa pesante ispirazione da logging di Java e che non sia stata concepita un'interfaccia piu' Pythonica del tutto. Tutta la separazione fra handler, formatter e combriccola cantante, sebbene cosa in se e per se buona e giusta fa veramente pensare ad un coso Java. Poi in Java hanno elaborato su logging con librerie crescentemente piu' elaborate e comode e noi siamo rimasti indietro -- nel senso che non conosco librerie alternative che siano largamente usate. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Stop using print for debugging
2015-06-23 7:41 GMT+01:00 Simone Federici :
> altro suggerento per loggare elementi costosi a livello computazionale
> tipo json.dumps() è wrapparli con isEnabledFor
>
> if logger.isEnabledFor(logging.DEBUG):
> logger.debug('dump: %s', json.dumps())
>
Un'altra possibilita' in questi casi (che a me piace di piu') ma che ha un
minimo costo (di sviluppo) ma lascia il codice piu' pulito e mantiene
l'efficienza a livello di codice marginalmente migliore e' introdurre dei
proxy.
Ovvero qualcosa come:
class JSONDumper(object):
def __init__(self, obj):
self.obj = obj
def __str__(self):
return json.dumps(self.obj)
e poi semplicemente:
logger.debug('dump: %s', JSONDumper(something))
Di fatto debug/info e compagnia hanno gia' dentro la logica per costruire
la stringa dai placeholder se e solo se la stringa viene attualmente
stampata su qualcosa (quindi il livello di logging e' giusto etc etc etc).
Un oggetto come quello che ho scritto di fatto si appoggia a questa logica.
Di fatto, puoi immaginare che logger.debug dentro abbia gia' un controllo
come logger.isEnabledFor(logging.DEBUG) e quindi, in pratica, lo staresti
chiamando due volte. Teoricamente hai anche potenzialmente il caso in cui
il logging level cambi fra le due chiamate, per quanto raro.
Dopo di che, ci sono una serie di casi in cui fare un proxy tipo quello la
sopra e' un overkill e la soluzione che suggerisci funziona bene per tutti
gli scopi pratici.
--
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] [ANN] Genropy migration tool
Il 23.06.2015 13:09, Giovanni Porcari ha scritto: Ciao a tutti Il framework Genropy ha come motto: "Python for lazy people". Per onorare questa promessa abbiamo ora reso disponibile, sia pure in una versione non definitiva, un nuovo tool che consente di costruire in pochi minuti e in modo automatico un'applicazione Genropy (package, model, views, forms e menu) a partire da un database esistente in sqlite, postgres, mysql o mssql, provvedendo anche all’importazione dei dati. Per far conoscere a chi fosse interessato le funzionalità di questo strumento, abbiamo realizzato un breve screencast, che mostrerà come, in pochi minuti, sia stato possibile, partendo dal database pubblico ‘Chinook’ (https://chinookdatabase.codeplex.com) creare una applicazione completa e perfettamente operativa. Lo screencast è disponibile su : https://vimeo.com/131523423 Si tratta di uno strumento appena rilasciato e quindi sono assai probabili intoppi e bachi ma se sarete così gentili da segnalarceli cercheremo di toglierli e di rendere il tutto più funzionale e piacevole da usare. In questa versione l’import è immediato e forse sarebbe opportuno in caso database di grandi dimensioni disaccoppiare la costruzione della applicazione dalla fase di import. Per il momento quindi non testatelo su db con centinaia di migliaia di record ;) Se qualche collega che usa Django avesse voglia di provare con un db non immenso per farmi sapere se funziona, potrebbe essere un buon punto di partenza per applicazioni Django con back-end in Genropy. Ricordo che ulteriori informazioni su genropy e sul migration tool sono disponibili sulla mailing list di genropy. Chi fosse interessato a iscriversi potrà inviare una mail con subject ‘subscribe’ a genropy-requ...@freelists.org oppure richiederlo a : http://www.freelists.org/list/genropy. Grazie e ciao :) G P.S. La qualità dell’audio è indecente e tutto lo screencast è abbastanza modesto come realizzazione. Ma ci ripromettiamo di farne una versione migliore appena possibile ;) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python Grandioso... sto studiando e imparando (nel mio poco tempo libero) Genropy, più lo conosco più mi piace... grazie per l'impegno e la passione che ci mettete :) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] [ANN] Genropy migration tool
Ciao a tutti Il framework Genropy ha come motto: "Python for lazy people". Per onorare questa promessa abbiamo ora reso disponibile, sia pure in una versione non definitiva, un nuovo tool che consente di costruire in pochi minuti e in modo automatico un'applicazione Genropy (package, model, views, forms e menu) a partire da un database esistente in sqlite, postgres, mysql o mssql, provvedendo anche all’importazione dei dati. Per far conoscere a chi fosse interessato le funzionalità di questo strumento, abbiamo realizzato un breve screencast, che mostrerà come, in pochi minuti, sia stato possibile, partendo dal database pubblico ‘Chinook’ (https://chinookdatabase.codeplex.com) creare una applicazione completa e perfettamente operativa. Lo screencast è disponibile su : https://vimeo.com/131523423 Si tratta di uno strumento appena rilasciato e quindi sono assai probabili intoppi e bachi ma se sarete così gentili da segnalarceli cercheremo di toglierli e di rendere il tutto più funzionale e piacevole da usare. In questa versione l’import è immediato e forse sarebbe opportuno in caso database di grandi dimensioni disaccoppiare la costruzione della applicazione dalla fase di import. Per il momento quindi non testatelo su db con centinaia di migliaia di record ;) Se qualche collega che usa Django avesse voglia di provare con un db non immenso per farmi sapere se funziona, potrebbe essere un buon punto di partenza per applicazioni Django con back-end in Genropy. Ricordo che ulteriori informazioni su genropy e sul migration tool sono disponibili sulla mailing list di genropy. Chi fosse interessato a iscriversi potrà inviare una mail con subject ‘subscribe’ a genropy-requ...@freelists.org oppure richiederlo a : http://www.freelists.org/list/genropy. Grazie e ciao :) G P.S. La qualità dell’audio è indecente e tutto lo screencast è abbastanza modesto come realizzazione. Ma ci ripromettiamo di farne una versione migliore appena possibile ;) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
