Re: [Python] Progetto SW

[Carlos Catucci]

2015-10-27 1:31 GMT+01:00 Manlio Perillo :

> I punti di forza di Python sono che è facile programmare e trovi
> librerie pronte per tutto
> (quindi giorni/settimane di lavoro risparmiati).
>

Magari dico una cazzata ma Plone? Avrebbe tabta roba gia' preconfigurata
per i suoi usi, e' validissimo per il documentale, zodb potrebbe essere il
solo Db da usare,m senza impastarsi con MAI(epoimai)Sql ne tirare fuori la
USS Enterprise e uno Star Destroyer messe assieme per risolvere un task
ordinario ;)

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Nicola Larosa]

Carlos Catucci wrote:
> Magari dico una cazzata ma Plone?

Hai detto una cazzata, anzi cazzatona. :-) (IMNSHO)


> ne tirare fuori la USS Enterprise e uno Star Destroyer messe assieme
> per risolvere un task ordinario ;)

Che è quello che hai appena fatto, solo che invece hai tirato fuori la
Morte Nera. ;-)

-- 
Nicola 'tekNico' Larosa 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Carlos Catucci]

2015-10-27 8:17 GMT+01:00 Nicola Larosa :

> Però sì, non c'è SQL migliore di PostgreSQL (che io sappia).
>

Dai benchmarck le versioni 9.3+ anche come NoSql sono al top


> E questa cosa tocca ripeterla ancora e ancora. Già mi vedo vecchio e
> canuto (magari) declamarla ai bambini nel parco, alle allodole in festa,
> a qualsiasi cosa ascolti e non:
>
> "Non usate maisìcuel... non usate maisìcuel..."
>
> "Ora basta nonno, non lo usa più nessuno da almeno vent'anni."
>
> Magari...
>

Lol, immagine poetica.
Pensa se Guccio dci riscrivesse su Il vecchio e il bambino. ;)

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Giovanni Porcari]

> Il giorno 27 ott 2015, alle ore 00:38, Marco Soldavini  
> ha scritto:
> 
> ciao a tutti
> 
> nell'ambito di un esperienza lavorativa recente ho avuto un idea per un tool 
> che mi tornerebbe utile.
> 
> In sostanza vorrei creare una sorte di applicazione in background in python 
> che si possa interfacciare con:
> 
> server MYSQL
> file CSV
> server OPC (uno standard industriale di comunicazione)
> 
> I dati in ingresso provengono dai file CSV (in maniera diciamo discreta ogni 
> tot tempo questi file vengono creati in una cartella da una applicazione 
> esterna e devono essere analizzati e inseriti con una query dentro il server 
> SQL)
> 
> Oltre al file CSV l applicazione deve fare polling sul server OPC per leggere 
> dati e memorizzarli (per successivo invio su SQL) oppure per fare trigger di 
> ulteriori azioni
> 
> Inoltre l applicazione deve essere in grado di generare un file PDF dal 
> server MYSQL contenente sia dati in forma tabellare che plot con la 
> generazione attivata in base ad un trigger esterno.
> 
> Sapete dirmi in quali punti vedete forte python e quali classi / librerie mi 
> consigliate considerando che devo fare:
> 
> parsing CSV
> interfacciarmi in lettura e scrittura con SQL
> generare PDF
> 
> (per il server OPC ho gia' dei toolkit e librerie)
> 
> E' un progetto complesso ma conto di riuscire a finirlo in poche settimane 
> impegni permettendo. Se a qualcuno interessa posso condividere i miei 
> risultati.
> 


A parte il fatto che come dice Nicola mysql è meglio lasciarlo stare,
per il tipo di applicazione che ti serve credo che Genropy potrebbe 
andare molto bene.

Abbiamo ancora problemi di documentazione ma ci stiamo lavorando,
in compenso la mailing list è molto attiva e stiamo crescendo bene.
Inoltre siamo dispostissimi a darti una mano perchè abbiamo il desiderio
di avere nuovi sviluppatori che usino il framework.

www.genropy.org
sandbox.genropy.org

Ciao

G.

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Nicola Larosa]

> Marco Soldavini wrote:
>> server MYSQL

Marco Beri wrote:
> Fatti un piacere: usa PostgreSQL.

O qualsiasi altra cosa, ma mai maisìcuel.

Però sì, non c'è SQL migliore di PostgreSQL (che io sappia).

Ennesimo data point, al nuovo lavoro: problemi incomprensibili col
database, spazzati via togliendo la suddetta piaga e mettendo PostgreSQL
(due settimane dopo il mio arrivo, non casualmente ;-) ).

E questa cosa tocca ripeterla ancora e ancora. Già mi vedo vecchio e
canuto (magari) declamarla ai bambini nel parco, alle allodole in festa,
a qualsiasi cosa ascolti e non:

"Non usate maisìcuel... non usate maisìcuel..."

"Ora basta nonno, non lo usa più nessuno da almeno vent'anni."

Magari...

-- 
Nicola 'tekNico' Larosa 

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Carlos Catucci]

2015-10-27 8:20 GMT+01:00 Nicola Larosa :

> Che è quello che hai appena fatto, solo che invece hai tirato fuori la
> Morte Nera.
>

Beh se devi fare una cosa tanto vale farla bene no? D'altronde distruggere
Alderaan non era una cosa di ordinaria amministrazione? :)

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Massimiliano Pippi]

2015-10-27 10:39 GMT+01:00 Andrea D'Amore :
> 2015-10-27 1:12 GMT+01:00 Massimiliano Pippi :
>> io affronterei il problema con Django
>> (https://www.djangoproject.com/), anche se non è verticale sul tuo
>> problema ha un sacco di robine che ti potrebbero far comodo.
>
> Però su quello deve imparare a conoscere django e quali sono le
> funzioni che gli tornano utili e non è immediato, magari le poche
> settimane diventano "poche per due".
>
da quello che traspare OP è alle prime armi con Python, "poche per
due" mi pare ottimistico in ogni caso, avrà molto da studiare
qualsiasi strada prenda.

> Poi si ritrova ad usare un framework web per scrivere un demone,
ho un po' tirato il cappello sui requisiti, dal messaggio originale
mancano diversi dettagli, ho scommesso sul fatto che avrà bisogno di
una qualche interazione con l'utente.
Poi magari mi sbaglio e ritiro tutto, ma dire che ha bisogno di un
demone è valido quanto dire che serve un'applicazione web.

> avrà
> anhe un sacco di funzioni che gil tornano utili ma si tira anche
> dentro un sacco di codice che non gli serve e non userà mai.
>
uhm... quindi? Ogni volta che usi Python ti tiri dietro un sacco di
codice della libreria standard che non usi, che fastidio ti da?

> Dato che ha delineato in maniera specifica il problema come leggere
> csv, interfacciarsi SQL e scrivere PDF io andrei dritto con questo.
>
Cioè? Manca tutta la logica applicativa, ovvio che i singoli problemi
che elenchi vanno affrontati come già suggerito in altri messaggi, ma
con che li tieni insieme?
Ho suggerito un'applicazione web per contenere il tutto ma come detto
potrebbe essere l'architettura sbagliata, la palla di vetro ancora non
ce l'ho :)

Ciao

-- 
M.

@maxpippi :: http://dev.pippi.im/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Andrea D'Amore]

2015-10-27 1:12 GMT+01:00 Massimiliano Pippi :
> io affronterei il problema con Django
> (https://www.djangoproject.com/), anche se non è verticale sul tuo
> problema ha un sacco di robine che ti potrebbero far comodo.

Però su quello deve imparare a conoscere django e quali sono le
funzioni che gli tornano utili e non è immediato, magari le poche
settimane diventano "poche per due".

Poi si ritrova ad usare un framework web per scrivere un demone, avrà
anhe un sacco di funzioni che gil tornano utili ma si tira anche
dentro un sacco di codice che non gli serve e non userà mai.

Dato che ha delineato in maniera specifica il problema come leggere
csv, interfacciarsi SQL e scrivere PDF io andrei dritto con questo.

-- 
Andrea
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Andrea D'Amore]

2015-10-27 10:56 GMT+01:00 Massimiliano Pippi :
> uhm... quindi? Ogni volta che usi Python ti tiri dietro un sacco di
> codice della libreria standard che non usi, che fastidio ti da?

In effetti nessuno e senz'altro lo faccio già.

> Cioè? Manca tutta la logica applicativa, ovvio che i singoli problemi
> che elenchi vanno affrontati come già suggerito in altri messaggi, ma
> con che li tieni insieme?

Io ho pensato ad una libreria per la gestione asincrona degli eventi,
mi sembra che il punto fondamentale sia quello.

> Ho suggerito un'applicazione web per contenere il tutto ma come detto
> potrebbe essere l'architettura sbagliata, la palla di vetro ancora non
> ce l'ho :)

Magari è un ottimo consiglio ma mi dà l'idea di usare uno strumento
fuori dal contesto che gli è proprio. Poi magari è solo che non
conosco bene Django.


-- 
Andrea
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Andrea D'Amore]

2015-10-27 0:38 GMT+01:00 Marco Soldavini :
> I dati in ingresso provengono dai file CSV (in maniera diciamo discreta ogni
> tot tempo

Sincrona o asincrona?

> questi file vengono creati in una cartella da una applicazione
> esterna e devono essere analizzati e inseriti con una query dentro il server
> SQL)

> Oltre al file CSV l applicazione deve fare polling sul server OPC per
> leggere dati e memorizzarli (per successivo invio su SQL) oppure per fare
> trigger di ulteriori azioni

Questo passaggio è alternativo al file CSV, cioè non leggi da OPC per
poi scrivere il file CSV e tornare al punto precedente?

> Inoltre l applicazione deve essere in grado di generare un file PDF dal
> server MYSQL contenente sia dati in forma tabellare che plot con la
> generazione attivata in base ad un trigger esterno.

> Sapete dirmi in quali punti vedete forte python e quali classi / librerie mi
> consigliate considerando che devo fare:
>
> parsing CSV
> interfacciarmi in lettura e scrittura con SQL
> generare PDF

I tre compiti che hai elencato sono semplici di per sé, vedo che ti
hanno già suggerito il modulo csv della libreria standard (ovviamente)
e reportlab, per SQL potresti usare un ORM come SQLAlchemy che ti
fornisce ad un livello di astrazione più alta  e ti permette di
nascondere il dbms che scegli. Il problema è che richiede un
apprendimento iniziale, per cui se a te serve fare "solo xSQL, solo in
questa occasione e poi mai più-issimo" magari ti conviene piuttosto
usare un modulo specifico per il tuo db e scrivere SQL a mano, e tutti
ti sono vicini in questo difficile momento. Per il plot matplotlib.

Secondo me la cosa fondamentale in questa applicazione, che immagino
sia un demone dato che parli di background, è l'interazione con i
processi esterni e qualcuno (non ricordo se su questa lista o su
altra) ha suggerito Celery.
Magari qualcuno che l'ha usato (io purtroppo no) può intervenire a
riguardo, è un tema interessante.

Per il trigger esterno pensi a qualcosa tipo  un server TCP/IP che
ascolta o IPC con i segnali?


-- 
Andrea
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Perini Matteo]

Il 26/10/2015 21:31, Manlio Perillo ha scritto:

Un ultimo consiglio.
Per testare funzioni come somma di solito è preferibile usare una
tabella con l'input e l'output corretto; ad esempio:

Fatto! grazie

Ora però ho un altro problema che non riesco a risolvere.
Riporto l'esempio di prima con il nuovo problema.

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

class CC():
def __init__(self):
self.a = 2
self.b = 4
self.c = 5
def menouno(self,x):
return x-1
def somma(self):
return self.menouno(self.a+self.b+self.c)


if __name__=="__main__":
tt=CC()
print(tt.somma())

la somma in questo caso fa 10

Il mio file di test ora è così:

from pt import CC

def test_somma():
CC.__init__(CC)
assert CC.somma(CC)==10

Ma in questo caso self.menouno da errore perchè riceve un solo parametro 
(dice che manca la x)


Se nel file metto "return self.menouno(self, self.a+self.b+self.c)" 
viene eseguito il test ma non va più il programma e viceversa!


Ho cercato nella documentazione ma non ho ancora trovato una soluzione.

Grazie per l'aiuto
M.






___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Giovanni Porcari]

> Il giorno 27 ott 2015, alle ore 13:07, enrico franchi 
>  ha scritto:
> 
> 
> 2015-10-27 9:39 GMT+00:00 Andrea D'Amore :
> Poi si ritrova ad usare un framework web per scrivere un demone, avrà
> anhe un sacco di funzioni che gil tornano utili ma si tira anche
> dentro un sacco di codice che non gli serve e non userà mai.
> 
> +1
> 
> E lo stesso si applica a Genropy e altri framework. Ora su G. non posso 
> esprimermi cosi' in dettaglio... su Django un pochetto di piu'.
> Ed e' dolore. 
> 

Genropy può funzionare tranquillamente anche come applicazione
da usare come script. Cioè ti da solo una sorta di ORM che a mio avviso
è più vicino al puro SQL rispetto ad un ORM classico e ti mette a disposizione
parecchia pappa fatta tra cui tutta la parte delle stampe e creazione dei PDF.
Inoltre se poi, per qualunque ragione, devi metterci una GUI allora basta far
partire il server e generare le risorse di view e form necessarie..

Però concordo con voi: se non c'è bisogno di una GUI è inutile usare
oggetti più complessi.



G


___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Manlio Perillo]

On Tue, Oct 27, 2015 at 1:47 PM, enrico franchi
 wrote:
>
> 2015-10-26 19:31 GMT+00:00 Manlio Perillo :
>>
>> Per testare funzioni come somma di solito è preferibile usare una
>> tabella con l'input e l'output corretto; ad esempio:
>>
>> table = [ ((1, 2, 3), 5), ((3, 5, 7), 15), ...]
>>
>> def test_somma():
>> for in, out in table:
>> cc = CC(*in)
>> assert cc.somma() == out
>>
>> CC(*in) è equivalente a CC(in[0], in[1], in[2]).
>
>
> Uhm... no. Questo e' un noto anti-pattern nel testing. Non si deve *mai*
> fare qualcosa del genere (a meno di non avere a che fare con un framework di
> test veramente primitivo).
>

> [...]

Bello, non lo conoscevo; grazie.
In effetti io uso solo unittest standard.

> http://xunitpatterns.com/Parameterized%20Test.html
>
> """
> Several early reviewers wrote to me about a variation they use regularly:
> the Tabular Test. The essence of this is the same as doing a Parameterized
> Test except that the entire table of values is in a single Test Method.
> Unfortunately, this makes the test an Eager Test (see Assertion Roulette on
> page X) because it verifies many test conditions. This isn't a problem when
> all the tests are passing but it does lead to a lack of Defect Localization
> (see Goals of Test Automation) when one of the rows fails.
> """

La libreria standard di Go usa questo metodo, ed in effetti può essere
visto come un problema.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[simozack]

Il giorno 27 ottobre 2015 11:47, Perini Matteo  ha
scritto:

> from pt import CC
>
> def test_somma():
> CC.__init__(CC)
> assert CC.somma(CC)==10


Occhio che anche il test deve essere codice Python buono! :)

Prova, ad esempio, a creare all'interno di test_somma una istanza valida di
CC e di fare l'assert su quella.

Ciao,
Simone
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[enrico franchi]

2015-10-27 12:29 GMT+00:00 Nicola Larosa :

> Ti riferisci a questo penosa, lagnosa ritirata?
>

Internet non dimentica.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Perini Matteo]

Il 27/10/2015 13:40, Manlio Perillo ha scritto:

Ti ho detto che non devi usare la classe in questo modo!
https://docs.python.org/2/tutorial

La classe la devi*instanziare*.

Pian piano si impara
Grazie dell'aiuto
M
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[enrico franchi]

2015-10-27 7:17 GMT+00:00 Nicola Larosa :

>
> O qualsiasi altra cosa, ma mai maisìcuel.
>

Fai rollback dell'affermazione di qualche mese fa che non avresti piu'
criticato MySQL perche' sembravano andati a posto? ;)
Oh, son con te... a me MySQL ha sempre e solo causato dolore.



> Già mi vedo vecchio e
> canuto (magari) declamarla ai bambini nel parco


Lasciando stare il parco...


> "Ora basta nonno, non lo usa più nessuno da almeno vent'anni."
>
> Magari...


Infatti. Non credo che ce ne libereremo.

-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[enrico franchi]

2015-10-27 10:00 GMT+00:00 Andrea D'Amore :

> Secondo me la cosa fondamentale in questa applicazione, che immagino
> sia un demone dato che parli di background, è l'interazione con i
> processi esterni e qualcuno (non ricordo se su questa lista o su
> altra) ha suggerito Celery.
>

Pensa che io ho dei dubbi perfino con Celery... e' un po' piu' vicino a
quello che gli serve, ma ha una complessita' operazionale piu' elevata di
un semplice demone che fa quello che gli serve.
In aggiunta, non mi risulta che Celery sia particolarmente adatto per fare
cose che reagiscono ad eventi esterni (a meno che gli eventi esterni non
siano appunto task sottomessi). E quindi dovrebbe sempre avere degli
observer che poi passano la palla a celery quando vedono qualche
avvenimento degno di nota.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Marco Soldavini]

2015-10-27 0:44 GMT+01:00 Marco Beri :

> 2015-10-27 0:38 GMT+01:00 Marco Soldavini :
>
>> server MYSQL
>>
>
> Fatti un piacere: usa Postgresql.
>
> Ciao.
> Marco.
>
> --
>
>
ciao, l'utilizzo del server potrebbe non essere libero (forse sono
costretto ad integrarlo in un ambiente windows con l SQL di microsoft.
comunque tengo presente il tuo suggerimento

marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[enrico franchi]

2015-10-27 9:39 GMT+00:00 Andrea D'Amore :

> Poi si ritrova ad usare un framework web per scrivere un demone, avrà
> anhe un sacco di funzioni che gil tornano utili ma si tira anche
> dentro un sacco di codice che non gli serve e non userà mai.
>

+1

E lo stesso si applica a Genropy e altri framework. Ora su G. non posso
esprimermi cosi' in dettaglio... su Django un pochetto di piu'.
Ed e' dolore.

Lui ha bisogno essenzialmente di un loop asincrono che legge dati da un
paio di fonti e le scrive in un database. Questo e' un classico demone di
monitoring, non c'e' alcun bisogno di usare roba web. Se si vuole poi una
UI per il tutto, allora tiriamo in ballo il web in aggiunta al demone.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[enrico franchi]

2015-10-27 9:56 GMT+00:00 Massimiliano Pippi :

> 2015-10-27 10:39 GMT+01:00 Andrea D'Amore :
> > 2015-10-27 1:12 GMT+01:00 Massimiliano Pippi :
> >> io affronterei il problema con Django
> >> (https://www.djangoproject.com/), anche se non è verticale sul tuo
> >> problema ha un sacco di robine che ti potrebbero far comodo.
> >
> > Però su quello deve imparare a conoscere django e quali sono le
> > funzioni che gli tornano utili e non è immediato, magari le poche
> > settimane diventano "poche per due".
> >
> da quello che traspare OP è alle prime armi con Python, "poche per
> due" mi pare ottimistico in ogni caso, avrà molto da studiare
> qualsiasi strada prenda.
>
> > Poi si ritrova ad usare un framework web per scrivere un demone,
>


> ho un po' tirato il cappello sui requisiti, dal messaggio originale
> mancano diversi dettagli, ho scommesso sul fatto che avrà bisogno di
> una qualche interazione con l'utente.
> Poi magari mi sbaglio e ritiro tutto, ma dire che ha bisogno di un
> demone è valido quanto dire che serve un'applicazione web.
>

Mah, puo' essere, eh. Pero' quello che dice sull'architettura e'
relativamente chiaro (poi magari incompleto e/o sbagliato).

Fondamentalmente lui ha un coso che deve stare in attesa di eventi, che
sono:
1. un nuovo file in una directory (parlare di cartelle punta
fortissimamente in direzione "prime armi", ma in direzione piu'
preoccupante che il solo Python)
2. un nuovo valore dal suo OPC
3. un'azione scatenata dall'utente

In tutto questo l'unico pezzo dove potrebbe avere qualche beneficio da
usare Django e' il 3, in compenso si troverebbe a lottare con 1 e 2.
Perche' farlo con i cron e i command di Django ha un mucchio di problemi
(fra cui di risoluzione, a meno che non tiri in ballo qualche altro
scheduler di jobs...).
Praticamente non vedo nulla che suggerisca che Django (e simili) facciano
al caso suo.

Anche perche' una volta che hai messo su un loop asincrono che ti fa 1 e 2,
aggiungere un sistema per fare 3 e' banale. Male che butta, SIGUSR1 e passa
la paura. E no... non e' che lo farei con i segnali (per una quintalata di
motivi, fra cui il fatto che il segnalatore deve essere sulla stessa box
del demone... in questo un normalissimo socket e' molto piu' adatto).



>
> > avrà
> > anhe un sacco di funzioni che gil tornano utili ma si tira anche
> > dentro un sacco di codice che non gli serve e non userà mai.
> >
> uhm... quindi? Ogni volta che usi Python ti tiri dietro un sacco di
> codice della libreria standard che non usi, che fastidio ti da?
>

Diciamo che tirare in ballo Django dove di Django puoi martellare a brutta
maniera una feature per fare una cosa che gli serve (in modo molto poco
ottimale) e non usare tutto il resto su cui Django e' forte non mi sembra
una delle idee migliori.


> Ho suggerito un'applicazione web per contenere il tutto ma come detto
> potrebbe essere l'architettura sbagliata, la palla di vetro ancora non
> ce l'ho :)
>

Che poi magari voglia *anche* un'applicazione web niente da dire. Ma il
cuore del suo sistema non assomiglia affatto ad un'applicazione web.

-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Nicola Larosa]

enrico franchi wrote:
> Fai rollback dell'affermazione di qualche mese fa che non avresti
> piu' criticato MySQL perche' sembravano andati a posto? ;)

Ti riferisci a questo penosa, lagnosa ritirata?



Quella non l'ho scritta io, ma qualche demone che si dev'essere
impadronito di me, o del mio computer.

Ma quali dimissioni, quale anziano: la gente che parla bene di maisìcuel
non può essere in gamba! Hasta la sputazzata siempre!

Sometimes life is commit, sometimes it is rollback indeed.

-- 
Nicola 'tekNico' Larosa 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Manlio Perillo]

2015-10-27 11:47 GMT+01:00 Perini Matteo :
> Il 26/10/2015 21:31, Manlio Perillo ha scritto:
>>
> [...]
> class CC():
> def __init__(self):
> self.a = 2
> self.b = 4
> self.c = 5
> def menouno(self,x):
> return x-1
> def somma(self):
> return self.menouno(self.a+self.b+self.c)
>
> [...]
>
> from pt import CC
>
> def test_somma():
> CC.__init__(CC)
> assert CC.somma(CC)==10
>

Ti ho detto che non devi usare la classe in questo modo!
https://docs.python.org/2/tutorial

La classe la devi *instanziare*.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[enrico franchi]

2015-10-26 19:31 GMT+00:00 Manlio Perillo :

> Per testare funzioni come somma di solito è preferibile usare una
> tabella con l'input e l'output corretto; ad esempio:
>
> table = [ ((1, 2, 3), 5), ((3, 5, 7), 15), ...]
>
> def test_somma():
> for in, out in table:
> cc = CC(*in)
> assert cc.somma() == out
>
> CC(*in) è equivalente a CC(in[0], in[1], in[2]).
>

Uhm... no. Questo e' un noto anti-pattern nel testing. Non si deve *mai*
fare qualcosa del genere (a meno di non avere a che fare con un framework
di test veramente primitivo).

http://xunitpatterns.com/Parameterized%20Test.html

"""
Several early reviewers wrote to me about a variation they use regularly:
the *Tabular Test*. The essence of this is the same as doing a *Parameterized
Test* except that the entire table of values is in a single Test Method
. Unfortunately, this makes
the test an *Eager Test*
 (see
Assertion Roulette on page X) because it verifies many test conditions
. This isn't a problem when
all the tests are passing but it does lead to a lack of Defect Localization
 (see Goals of Test Automation) when one of the rows fails.
"""

Se si usa Nose:
https://nose.readthedocs.org/en/latest/writing_tests.html#test-generators

Se si usa PyTest:
https://pytest.org/latest/parametrize.html

-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Giovanni Porcari]

> Il giorno 27 ott 2015, alle ore 15:20, enrico franchi 
>  ha scritto:
> 
> 
> 2015-10-27 13:03 GMT+00:00 Giovanni Porcari :
> Genropy può funzionare tranquillamente anche come applicazione
> da usare come script.
> 
> Ma lui non ha bisogno di "uno script". Lui ha bisogno di un demone che stia 
> vivo a lungo.
> In questo senso il main loop e' quello di un demone... poi che ci siano 
> librerie dentro Genropy che possano essere utili e' un altro discorso...
>  
> Cioè ti da solo una sorta di ORM che a mio avviso
> è più vicino al puro SQL rispetto ad un ORM classico e ti mette a disposizione
> 
> E questo secondo me non e' eccessivamente utile per il suo caso. Se immagino 
> correttamente il suo problema, le query (sia di input che di output) saranno 
> parecchio semplici.
> Mi aspetto che abbia dati relativamente poco relazionali, essenzialmente dei 
> tsd praticamente piatti.
>  
> parecchia pappa fatta tra cui tutta la parte delle stampe e creazione dei PDF.
> 
> Questa invece potrebbe essere particolarmente interessante. reportlab e' 
> molto complesso, ed e' possibile che la facade che tu gli offri sia piu' 
> comoda.
> 
> Poi, a me non fa impazzire dipendere da un progetto "grosso" con N componenti 
> per usarne solo una.
> Essenzialmente per questione di gestione degli update in produzione.
> 
> 


Concordo su tutto. In effetti potrei anche vedere di rilasciare la parte stampe 
(che di fatto è molto snella) in modo che sia usabile al di fuori di Genropy.
Comunque come descrizione iniziale era abbastanza succinta ;)

G



___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[enrico franchi]

On Tue, Oct 27, 2015 at 1:30 PM, Manlio Perillo 
wrote:

>
> Bello, non lo conoscevo; grazie.
> In effetti io uso solo unittest standard.
>

https://github.com/rik0/ParamUnittest

Feel free to contribute.

Che io sappia ci sono solo un paio di magagne se hai ereditarieta'
complicata nei TestCase.


>
> La libreria standard di Go usa questo metodo, ed in effetti può essere
> visto come un problema.


In realta' non lo e'. Il punto e' che tutto questo discorso dei test e'
nato attorno ad una primitiva come assert che quando hai un problema
essenzialmente interrompe l'esecuzione li (tipicamente tirando
un'eccezione) e quindi le asserzioni successive non vengono eseguite.

La semantica dei test di Go invece e' basata attorno a primitive che
marcano il test fallito, ma proseguono con l'esecuzione. Quindi, di fatto,
buona parte dei problemi non ci sono piu'.
Personalmente la trovo una scelta eccellente, visto che e' molto piu'
facile da usare e di default porta meno problemi di assert.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[enrico franchi]

2015-10-27 14:39 GMT+00:00 Nicola Larosa :

> E Tornado è una anche migliore, secondo uno che ha usato Twisted per
> sette anni (e Tornado quasi per nulla :-) ), e che ne era il gestore del
> sito web, una volta.
>

Ottimo, direi. Twisted ha una pessima fama (poco meritata, sempre a mio
avviso).
Se Tornado mi risolve lo stesso problema e lo fa meglio, e' probabilmente
piu' facile da farlo accettare.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Manlio Perillo]

2015-10-27 15:51 GMT+01:00 enrico franchi :
> [...]
>> La libreria standard di Go usa questo metodo, ed in effetti può essere
>> visto come un problema.
>
>
> In realta' non lo e'. Il punto e' che tutto questo discorso dei test e' nato
> attorno ad una primitiva come assert che quando hai un problema
> essenzialmente interrompe l'esecuzione li (tipicamente tirando un'eccezione)
> e quindi le asserzioni successive non vengono eseguite.
>

Questo comportamento non è del tutto irragionevole.
Considera un test case in cui devo testare che un array non sia NULL e
che contenga una serie di caratteri.
Se il test assert p != NULL fallisce, il test case *deve* essere terminato.

Tempo fa avevo sviluppato una libreria per l'unit testing in C (oddio,
quanto codice ho che non ho mai publicato...).
La libreria usa il protocollo TAP, eppure avevo deciso di interrompere
l'esecuzione della funzione di test
in caso di fallimento, anche se non necessario (usando longjmp),
perchè mi sembrava la scelta più ragionevole.

> La semantica dei test di Go invece e' basata attorno a primitive che marcano
> il test fallito, ma proseguono con l'esecuzione. Quindi, di fatto, buona
> parte dei problemi non ci sono piu'.
> Personalmente la trovo una scelta eccellente, visto che e' molto piu' facile
> da usare e di default porta meno problemi di assert.
>

Non so perchè ero convinto che il test fosse interrotto in caso di
fallimento, anche se la documentazione
è chiara.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Manlio Perillo]

2015-10-27 15:02 GMT+01:00 Marco Soldavini :
>
>
> 2015-10-27 11:00 GMT+01:00 Andrea D'Amore :
>>
>> 2015-10-27 0:38 GMT+01:00 Marco Soldavini :
>> > I dati in ingresso provengono dai file CSV (in maniera diciamo discreta
>> > ogni
>> > tot tempo
>>
>> Sincrona o asincrona?
>>
>
> Il funzionamento spiegato meglio, magari apro un thread a parte, è il
> seguente:
>
> nell'architettura ci sono due entità
> A è la macchina che genera i file CSV, e i tag OPC (generalmente un sistema
> windows embedded)
> B è la macchina dove gira il mio applicativo in background
>


> A è collegata ad una macchina comandata da operatore che lavora a lotti
> discreti di produzione.
> per esempio l'operatore preme START BATCH e questo è un trigger OPC per
> iniziare la registrazione in OPC dei tag
> generati da A.
>

Questo dovrebbe essere facile, se hai il supporto per OPC pronto.

> Quando l'operatore preme STOP BATCH la mia applicazione smette di leggere e
> memorizzare i dati OPC.
> Successivamente la macchina A ha generato due file csv che provvede a
> spostare su B (oppure in base al trigger STOP BATCH la mia applicazione
> sposta i file da A  con un metodo da decidere)
>

Questo non mi sembra banalissimo.
Se A sposta i files csv su B, allora è facile.
Altrimenti potresti avere una race condition, con A che accede ai
files prima che vengano generati completamente.
Per il trasporto io userei un protocollo custom su TLS, magari usando
ZeroMQ (ma la moda del momento è abusare di HTTP).

> Successivamente l'app deve
>
> prendere i dati registrati e inserirli in un database di qualche tipo
> prendere i 2 file CSV, fare parsing e inserirli nellio stesso db di cui
> sopra.
> generare un file PDF contenente come già detto i dati registrati dai file
> CSV e da OPC
>

Io farei in questo modo.

Applicazione principale con eventuale UI che lancia N sotto processi
(con multiprocess).

1) Un processo lancia il server OPC e resta in ascolto dei dati, li
riceve e li scrive su database; quindi notifica il processo padre che
ha terminato
(magari terminando, se applicabile).
2) Un processo lancia il server TLS o HTTPS per ricevere i file CSV,
li legge ed invia il contenuto su database.
   Quando ha finito notifica il padre.
3) Quando il padre vede che i due processi hanno finito, ne lancia un
terzo che preleva i dati dal database e genera il PDF


Non mi viene in mente soluzione più semplice.
Non hai bisogno di programmazione asincrona, dato che i server in
pratica servono una sola richiesta alla volta.
Il punto più critico è vedere se puoi disaccoppiare la scrittura su
database da una lettura successiva.
Perchè complicarsi la vita introducendo una componente aggiuntiva come
celery se hai già il database?


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Massimiliano Pippi]

2015-10-27 13:18 GMT+01:00 enrico franchi :
>
> 2015-10-27 10:00 GMT+00:00 Andrea D'Amore :
>>
>> Secondo me la cosa fondamentale in questa applicazione, che immagino
>> sia un demone dato che parli di background, è l'interazione con i
>> processi esterni e qualcuno (non ricordo se su questa lista o su
>> altra) ha suggerito Celery.
>
>
> Pensa che io ho dei dubbi perfino con Celery...

Io sono un po' più convinto che non valga la pena: tira su il broker,
tira su il master, monitora i worker... ed alla fine hai sempre e
comunque uno scheduler stile cron (ok, ordini di grandezza più
flessibile ma sempre uno scheduler rimane).

-- 
M.

@maxpippi :: http://dev.pippi.im/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[enrico franchi]

2015-10-27 13:03 GMT+00:00 Giovanni Porcari :

> Genropy può funzionare tranquillamente anche come applicazione
> da usare come script.
>

Ma lui non ha bisogno di "uno script". Lui ha bisogno di un demone che stia
vivo a lungo.
In questo senso il main loop e' quello di un demone... poi che ci siano
librerie dentro Genropy che possano essere utili e' un altro discorso...


> Cioè ti da solo una sorta di ORM che a mio avviso
> è più vicino al puro SQL rispetto ad un ORM classico e ti mette a
> disposizione
>

E questo secondo me non e' eccessivamente utile per il suo caso. Se
immagino correttamente il suo problema, le query (sia di input che di
output) saranno parecchio semplici.
Mi aspetto che abbia dati relativamente poco relazionali, essenzialmente
dei tsd praticamente piatti.


> parecchia pappa fatta tra cui tutta la parte delle stampe e creazione dei
> PDF.
>

Questa invece potrebbe essere particolarmente interessante. reportlab e'
molto complesso, ed e' possibile che la facade che tu gli offri sia piu'
comoda.

Poi, a me non fa impazzire dipendere da un progetto "grosso" con N
componenti per usarne solo una.
Essenzialmente per questione di gestione degli update in produzione.





-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Marco Soldavini]

2015-10-27 15:07 GMT+01:00 Massimiliano Pippi :

>
> Ti do ragione pressoché su tutto ma non voglio sembrare quello che
> tira framework ai problemi e mi rendo conto che la mia soluzione era
> biased dall'idea che:
>
> 1) non mi fraintendete e ti prego OP non offenderti, ma alcune delle
> richieste denotavano inesperienza nel campo e tirare su un loop
> asincrono in python non è roba da newcomer
>

i know. ho esperienza nella realizzazione e configurazione di altre
soluzioni ma non di una fatta
da me in python.
è un task complesso, ma l'ho già affrontato in passato e questa volta
vorrei analizzarlo meglio e creare
una soluzione che non dipenda da package commerciali.


> 2) mi figuravo lui o chi per lui che ad un certo punto vuol "vedere"
> quello che sta succedendo

3) non ha parlato di scheduling per la creazione di PDF, ripeto sono
> biased io ma mi immaginavo già lui che va nell'admin e si genera il
> pdf su richiesta. E poi magari li vuol mandare via mail. E magari
> prima di generarli li vuole solo vedere. E magari... (perdonate lo
> sfogo, storie di freelancing :)
>
>
la generazione su richiesta in effetti potrebbe essere un requisito in
certi applicazioni possibili.
per ora mi basta la generazione fatta in base ad un trigger da OPC piu un
tempo di ritardo per permettere:

il trasferimento dei file CSV alla macchina dove gira l'applicativo in
python
il parsing e inserimento degli stessi nel DB.

cmq le vostre risposte mi hanno già dato diversi spunti su cui lavorare.
grazie!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Nicola Larosa]

Massimiliano Pippi wrote:
> Oh intendiamoci, per me si poteva pure rispondere "guarda, lascia 
> perdere Python perché si fa con un numero accettabile di righe di Go" 
> :)

Bash, un numero accettabile di righe di bash (mai nome fu più appropriato).

-- 
Nicola 'tekNico' Larosa 

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[enrico franchi]

2015-10-27 14:07 GMT+00:00 Massimiliano Pippi :

> 2015-10-27 13:14 GMT+01:00 enrico franchi :
> > Perche' farlo con i cron e i command di Django ha un mucchio di problemi
> > (fra cui di risoluzione, a meno che non tiri in ballo qualche altro
> > scheduler di jobs...).
>
> Yep, l'ho scritto infatti...
>
> >
> > Diciamo che tirare in ballo Django dove di Django puoi martellare a
> brutta
> > maniera una feature per fare una cosa che gli serve (in modo molto poco
> > ottimale)
> Ti do ragione pressoché su tutto ma non voglio sembrare quello che
> tira framework ai problemi e mi rendo conto che la mia soluzione era
> biased dall'idea che:
>
> 1) non mi fraintendete e ti prego OP non offenderti, ma alcune delle
> richieste denotavano inesperienza nel campo e tirare su un loop
> asincrono in python non è roba da newcomer
>

Si, puo' essere. E' una cosa che a me non e' mai sembrata complicata, io ho
sempre trovato Twisted completamente lineare.
Il che vuole dire probabilmente che sono io ad avere la testa contorta.

Comunque, adesso c'e' asyncio e compagnia briscola e sembra fatto quasi
apposta.

La questione e' che lui vuole tenere Windows sulla macchina B e io non so
come aiutarlo.
Se usasse Linux una roba tipo vedere quando compare un file e processarlo
e' una banalita' sconvolgente con inotity.
Pero' non ho idea di come si faccia con windows.


> 2) mi figuravo lui o chi per lui che ad un certo punto vuol "vedere"
> quello che sta succedendo
>

Se e' vero che tutto lo stato e' nel db, poi potrebbe avere una
applicazione web super-semplice che legge dal db.


> 3) non ha parlato di scheduling per la creazione di PDF, ripeto sono
> biased io ma mi immaginavo già lui che va nell'admin e si genera il
> pdf su richiesta. E poi magari li vuol mandare via mail. E magari
> prima di generarli li vuole solo vedere. E magari... (perdonate lo
> sfogo, storie di freelancing :)
>
> > e non usare tutto il resto su cui Django e' forte non mi sembra
> > una delle idee migliori.
> >
> ORM, admin, template engine, mi pareva abbastanza per giustificare la
> dipendenza.
>

Eh, ma invece secondo me l'ORM non serve (vedi quello che dicevo a
Giovanni: il tipo di dati che manipola non beneficia troppo da un ORM --
anzi --).
Admin non mi e' chiaro perche' dovrebbe servirgli in modo particolare.
E il template engine gli serve solo per fare la ui, se e quando la deve
fare.


> Anche perché se l'alternativa deve essere SQLAlchemy, Twisted o
> Tornado o peggio Celery + script in giro ristiamo lì.
>

Secondo me SQLAlchemy non gli serve. Twisted e' una buona alternativa per
non doversi sbattere a scrivere il runloop.



> Oh intendiamoci, per me si poteva pure rispondere "guarda, lascia
> perdere Python perché si fa con un numero accettabile di righe di Go"
>

Non ho idea di come bene giri Go su Windows. Io non tratto windows e non lo
voglio trattare.

Mi aspetto che il dotnetto abbia in effetti tutto quello che gli serve.
Anche in Java, in effetti, saprei come farlo abbastanza in modo semplice.

In Python potrebbe essere piu' complicato [nel senso che Python su windows
io non lo copro, quindi fatico a stabilire a basso livello cosa gli serve e
se ci sono librerie con api piu' newb friendly che lo possono aiutare].


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[enrico franchi]

2015-10-27 14:13 GMT+00:00 Massimiliano Pippi :

> Io sono un po' più convinto che non valga la pena: tira su il broker,
> tira su il master, monitora i worker... ed alla fine hai sempre e
> comunque uno scheduler stile cron (ok, ordini di grandezza più
> flessibile ma sempre uno scheduler rimane).
>

Concordo. E infatti cron (o eventuali versioni migliorate) non e' il
sistema giusto per questo.
Lui deve proprio fare polling asincrono degli eventi.

Alternativamente, se avesse celery, la cosa si giustificherebbe se la
famosa "macchina A", quando il tipo scrive STOP BATCH sottomettesse un task
sulla coda su cui celery legge.
Ma non mi e' chiaro quanto grado di liberta' si abbia nel fare questo.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Nicola Larosa]

enrico franchi wrote:
> io ho sempre trovato Twisted completamente lineare. Il che vuole dire
> probabilmente che sono io ad avere la testa contorta.

"Nulla da aggiungere, vostro onore."


> Comunque, adesso c'e' asyncio e compagnia briscola e sembra fatto 
> quasi apposta.

Dove "quasi apposta" sta per "una reimplementazione del core di Twisted
con l'API curiosamente triplicata".


> Secondo me SQLAlchemy non gli serve. Twisted e' una buona alternativa 
> per non doversi sbattere a scrivere il runloop.

E Tornado è una anche migliore, secondo uno che ha usato Twisted per
sette anni (e Tornado quasi per nulla :-) ), e che ne era il gestore del
sito web, una volta.

Se non altro per la documentazione e il supporto ormai pluriennale a
websocket e Python 3...


> Non ho idea di come bene giri Go su Windows.

Pare bene, ma...


> Io non tratto windows e non lo voglio trattare.

...appunto.

-- 
Nicola 'tekNico' Larosa 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Marco Soldavini]

2015-10-27 11:00 GMT+01:00 Andrea D'Amore :

> 2015-10-27 0:38 GMT+01:00 Marco Soldavini :
> > I dati in ingresso provengono dai file CSV (in maniera diciamo discreta
> ogni
> > tot tempo
>
> Sincrona o asincrona?
>
>
Il funzionamento spiegato meglio, magari apro un thread a parte, è il
seguente:

nell'architettura ci sono due entità
A è la macchina che genera i file CSV, e i tag OPC (generalmente un sistema
windows embedded)
B è la macchina dove gira il mio applicativo in background

A è collegata ad una macchina comandata da operatore che lavora a lotti
discreti di produzione.
per esempio l'operatore preme START BATCH e questo è un trigger OPC per
iniziare la registrazione in OPC dei tag
generati da A.

Quando l'operatore preme STOP BATCH la mia applicazione smette di leggere e
memorizzare i dati OPC.
Successivamente la macchina A ha generato due file csv che provvede a
spostare su B (oppure in base al trigger STOP BATCH la mia applicazione
sposta i file da A  con un metodo da decidere)

Successivamente l'app deve

prendere i dati registrati e inserirli in un database di qualche tipo
prendere i 2 file CSV, fare parsing e inserirli nellio stesso db di cui
sopra.
generare un file PDF contenente come già detto i dati registrati dai file
CSV e da OPC




>
> > Oltre al file CSV l applicazione deve fare polling sul server OPC per
> > leggere dati e memorizzarli (per successivo invio su SQL) oppure per fare
> > trigger di ulteriori azioni
>
> Questo passaggio è alternativo al file CSV, cioè non leggi da OPC per
> poi scrivere il file CSV e tornare al punto precedente?
>
>
fai riferimento a quanto spiegato sopra


> > Inoltre l applicazione deve essere in grado di generare un file PDF dal
> > server MYSQL contenente sia dati in forma tabellare che plot con la
> > generazione attivata in base ad un trigger esterno.
>
> > Sapete dirmi in quali punti vedete forte python e quali classi /
> librerie mi
> > consigliate considerando che devo fare:
> >
> > parsing CSV
> > interfacciarmi in lettura e scrittura con SQL
> > generare PDF
>
>
>
> Per il trigger esterno pensi a qualcosa tipo  un server TCP/IP che
> ascolta o IPC con i segnali?
>
>
>
Il trigger è un tag OPC che viene costantemente monitorato
dall'applicazione in python

Le limitazioni nell'implementazione sono in genere date dall'ambiente in
cui vanno inserite (da valutare)

Le macchine sono
A) Windows embedded
B) Windows Server

Il database da usare potrebbe essere Microsoft perchè i dati devono anche
essere trattati da altre applicazioni

ciao!
marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Progetto SW

[Massimiliano Pippi]

2015-10-27 13:14 GMT+01:00 enrico franchi :
> Perche' farlo con i cron e i command di Django ha un mucchio di problemi
> (fra cui di risoluzione, a meno che non tiri in ballo qualche altro
> scheduler di jobs...).

Yep, l'ho scritto infatti...

>
> Diciamo che tirare in ballo Django dove di Django puoi martellare a brutta
> maniera una feature per fare una cosa che gli serve (in modo molto poco
> ottimale)
Ti do ragione pressoché su tutto ma non voglio sembrare quello che
tira framework ai problemi e mi rendo conto che la mia soluzione era
biased dall'idea che:

1) non mi fraintendete e ti prego OP non offenderti, ma alcune delle
richieste denotavano inesperienza nel campo e tirare su un loop
asincrono in python non è roba da newcomer
2) mi figuravo lui o chi per lui che ad un certo punto vuol "vedere"
quello che sta succedendo
3) non ha parlato di scheduling per la creazione di PDF, ripeto sono
biased io ma mi immaginavo già lui che va nell'admin e si genera il
pdf su richiesta. E poi magari li vuol mandare via mail. E magari
prima di generarli li vuole solo vedere. E magari... (perdonate lo
sfogo, storie di freelancing :)

> e non usare tutto il resto su cui Django e' forte non mi sembra
> una delle idee migliori.
>
ORM, admin, template engine, mi pareva abbastanza per giustificare la
dipendenza.
Anche perché se l'alternativa deve essere SQLAlchemy, Twisted o
Tornado o peggio Celery + script in giro ristiamo lì.

Oh intendiamoci, per me si poteva pure rispondere "guarda, lascia
perdere Python perché si fa con un numero accettabile di righe di Go"
:)

-- 
M.

@maxpippi :: http://dev.pippi.im/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python