Re: [Python] Applicazione WEB con Python e Postgresql

2014-10-06 Per discussione Giovanni Porcari 

> Il giorno 07/ott/2014, alle ore 00:26, enrico franchi 
>  ha scritto:
> 
> 2014-10-05 11:34 GMT+01:00 Enrico Bianchi :
> 
> Python e` ad oggetti, ed implementa ogni sua caratteristica secondo questo 
> paradigma. Pero` Python permette di scrivere codice sia usando il metodo 
> procedurale (ovvero come C, Pascal, Go), sia usando il metodo ad oggetti 
> classico (Java, C#, Delphi).
> 
> Secondo me tu stai confondendo uno *stile* di programmazione (o se vuoi, di 
> design) con il supporto sintattico ed eventualmente semantico di un 
> linguaggio a quello stile. Lasciando perdere Pascal che so che a te piace e a 
> me fa un po' lasciamo perdere...
> 
> C'era anche un bellissimo libro sulla programmazione ad oggetti in C. Come 
> come? C. Si. C. Non C++. C.
> Eccome avranno fatto? Leggitelo. 
> 
> D'altra parte, senza andare lontano, prendi Python, apri il cofano e guarda 
> come e' fatto.
> 
> E troverai guarda un po'... C. C ad oggetti. Pesantemente ad oggetti. Trovi 
> relazioni di incapsulamento, polimorfismo (gia' gia'), ereditarieta'. Trovi 
> proprio tutto. E si, in C.
> 
> Ma in effetti... ci sono parecchi esempi, piu' o meno riusciti. gobject e' C. 
> E non direi che non e' roba ad oggetti.
> Ma anche robbe piu' strane. Tipo guardati come fanno quelli di gmp. E vedrai 
> che gli oggetti... scusa... gli interi di gmp tendono proprio a comportarsi 
> come oggetti. Tipicamente prima di usarli devi chiamare un costruttore... no, 
> scusa, un metodo, no scusa, una funzione _init, quando li distruggi, no 
> scusa, li deallochi, devi chiamare un distruttore, no scusa, un metodo, no 
> scusa, una funzione (che non ricordo se e' _free o _delete o checcavolo).
>  
> E non e` che uno dei due metodi sia meglio dell'altro, semplicemente uno usa 
> quello che meglio si adatta al proprio scopo.
> 
> Uhm... sara'. Il fatto fondamentale e' che io ho la forte sensazione di stare 
> programmando ad oggetti anche quando non sto definendo classi... Ora questa 
> potrebbe essere la scusa geniale per chi non conosce la programmazione ad 
> oggetti per asserire di stare programmando ad oggetti. Ma davvero...
> 
> Il problema e' che tutto il problema e' che non c'e' manco una definizione di 
> programmazione ad oggetti. O meglio... ce ne sono mille. E ognuna enfatizza 
> un qualche aspetto, si rifa' a qualche linguaggio "pioniere" e/o a qualche 
> padre della programmazione ad oggetti. 
> 
> Ora personalmente la parte che mi interessa meno e' l'aspetto sintattico 
> della faccenda. Certo, fare programmazione ad oggetti senza avere particolare 
> supporto da parte del linguaggio tende ad essere notevolmente piu' scomodo. 
> Chesso'... ti devi popolare una vtable a mano (tipo, guarda come sono 
> implementati i tipi in Python, sotto sotto). Che oggettivamente farei anche a 
> meno tutti i giorni. E infatti non scrivo una vm tutti i giorni.
> 
> Quindi puoi scrivere codice veramente non ad oggetti in Python? Certo. Puoi 
> farlo anche in Java. static anyone?
> Se poi mi chiedi una code review non ti aspettare di non dover passare sul 
> mio cadavere, ma l'idea e' un po' quella.
> 
> Tipicamente le idee alla base della progettazione ad oggetti sono *talmente* 
> buone [si lo so, non ho definito quello che e', almeno per me] che e' 
> *difficile* sostenere che farne a meno sia una buona idea.
>  
> L'assioma "la programmazione ad oggetti e` meglio della programmazione 
> procedurale" e` un concetto di Java e (penso) di C# che sta bene in quei 
> contesti (anche perche` non hai scelta), ma che mal si adatta a Python, 
> proprio perche` in quest'ultimo hai una metodologia di programmazione 
> totalmente differente
> 
> Uhm... no. Cerchiamo di capire cosa sia la programmazione ad oggetti e cosa 
> sia la programmazione procedurale. Vediamo cosa offre la seconda piu' della 
> prima, cosa offra la prima piu' della seconda e traiamo le ovvie conclusioni.
>  
> 
> 

Questa mail è una delle ragioni per cui vale la pena di sopportare i flame 
per il top quoting in questa lista. 
La leggi e dici 'cazzo che modo elegante e preciso di spiegare le cose'.

Grazie Enrico.. mattina iniziata bene :)

G

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

Re: [Python] Applicazione WEB con Python e Postgresql

2014-10-06 Per discussione enrico franchi 
2014-10-05 11:34 GMT+01:00 Enrico Bianchi :

>
> Python e` ad oggetti, ed implementa ogni sua caratteristica secondo questo
> paradigma. Pero` Python permette di scrivere codice sia usando il metodo
> procedurale (ovvero come C, Pascal, Go), sia usando il metodo ad oggetti
> classico (Java, C#, Delphi).


Secondo me tu stai confondendo uno *stile* di programmazione (o se vuoi, di
design) con il supporto sintattico ed eventualmente semantico di un
linguaggio a quello stile. Lasciando perdere Pascal che so che a te piace e
a me fa un po' lasciamo perdere...

C'era anche un bellissimo libro sulla programmazione ad oggetti in C. Come
come? C. Si. C. Non C++. C.
Eccome avranno fatto? Leggitelo.

D'altra parte, senza andare lontano, prendi Python, apri il cofano e guarda
come e' fatto.

E troverai guarda un po'... C. C ad oggetti. Pesantemente ad oggetti. Trovi
relazioni di incapsulamento, polimorfismo (gia' gia'), ereditarieta'. Trovi
proprio tutto. E si, in C.

Ma in effetti... ci sono parecchi esempi, piu' o meno riusciti. gobject e'
C. E non direi che non e' roba ad oggetti.
Ma anche robbe piu' strane. Tipo guardati come fanno quelli di gmp. E
vedrai che gli oggetti... scusa... gli interi di gmp tendono proprio a
comportarsi come oggetti. Tipicamente prima di usarli devi chiamare un
costruttore... no, scusa, un metodo, no scusa, una funzione _init, quando
li distruggi, no scusa, li deallochi, devi chiamare un distruttore, no
scusa, un metodo, no scusa, una funzione (che non ricordo se e' _free o
_delete o checcavolo).


> E non e` che uno dei due metodi sia meglio dell'altro, semplicemente uno
> usa quello che meglio si adatta al proprio scopo.


Uhm... sara'. Il fatto fondamentale e' che io ho la forte sensazione di
stare programmando ad oggetti anche quando non sto definendo classi... Ora
questa potrebbe essere la scusa geniale per chi non conosce la
programmazione ad oggetti per asserire di stare programmando ad oggetti. Ma
davvero...

Il problema e' che tutto il problema e' che non c'e' manco una definizione
di programmazione ad oggetti. O meglio... ce ne sono mille. E ognuna
enfatizza un qualche aspetto, si rifa' a qualche linguaggio "pioniere" e/o
a qualche padre della programmazione ad oggetti.

Ora personalmente la parte che mi interessa meno e' l'aspetto sintattico
della faccenda. Certo, fare programmazione ad oggetti senza avere
particolare supporto da parte del linguaggio tende ad essere notevolmente
piu' scomodo. Chesso'... ti devi popolare una vtable a mano (tipo, guarda
come sono implementati i tipi in Python, sotto sotto). Che oggettivamente
farei anche a meno tutti i giorni. E infatti non scrivo una vm tutti i
giorni.

Quindi puoi scrivere codice veramente non ad oggetti in Python? Certo. Puoi
farlo anche in Java. static anyone?
Se poi mi chiedi una code review non ti aspettare di non dover passare sul
mio cadavere, ma l'idea e' un po' quella.

Tipicamente le idee alla base della progettazione ad oggetti sono
*talmente* buone [si lo so, non ho definito quello che e', almeno per me]
che e' *difficile* sostenere che farne a meno sia una buona idea.


> L'assioma "la programmazione ad oggetti e` meglio della programmazione
> procedurale" e` un concetto di Java e (penso) di C# che sta bene in quei
> contesti (anche perche` non hai scelta), ma che mal si adatta a Python,
> proprio perche` in quest'ultimo hai una metodologia di programmazione
> totalmente differente


Uhm... no. Cerchiamo di capire cosa sia la programmazione ad oggetti e cosa
sia la programmazione procedurale. Vediamo cosa offre la seconda piu' della
prima, cosa offra la prima piu' della seconda e traiamo le ovvie
conclusioni.


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

[Python] UDP+OOB e Conferenza Red Hat il 6 nov Roma

2014-10-06 Per discussione Remo The Last 
Ciao lista,
insisto una volta di più con OOB ma stavolta trasportati da UDP (TCP ho 
risolto).
Ho cercato di tutto in linea e fatto varie prove con il sendto() di python, ma 
sembra che OOB non sia implementato in python UDP. Se qualcuno sa come fare un 
sendto() con OOB mi faccia sapere.

Un'altra cosa. Il 6 novembre ci sarà a Roma una Conferenza Red Hat come già in 
passato.
Se qualcun'altro della lista sarà presente magari ci si incontra e ci si prende 
un buon caffè per conoscerci.

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

Re: [Python] Agile programming Robert Martin

2014-10-06 Per discussione Marco Beri 
2014-10-06 10:52 GMT+02:00 Nicola Larosa :

> Marco Beri wrote:
>
> > Non direi certo che il commento del tuo esempio è una sconfitta del
> > programmatore, ma venendo da un'epoca in cui il codice DOVEVA essere
> > commentato,
>
> Un'epoca? Il codice deve essere commentato e descritto anche oggi.
>

Dai, hai capito cosa intendevo :-)

Una volta si diceva che tutto il codice doveva per forza essere molto
commentato.

> la definizione seguente mi ha abbastanza colpito: "ogni commento non
> > banale è un insuccesso del programmatore che non è riuscito a scrivere
> > del codice auto-esplicativo".
>
> Credo sia questa:
>
> "Comments are, at best, a necessary evil. If our programming languages
> were expressive enough, or if we had the talent to subtly wield those
> languages to express our intent, we would not need comments very
> much—perhaps not at all."


> L'autore descrive in modo articolato pregi e difetti dei commenti; il suo
> giudizio complessivo che sia un "male necessario" mi sembra miope.
>

Io lo trovo invece sostanzialmente comprensibile e corretto. Il senso del
male necessario sta nel fatto che un commento è in fondo un possibile punto
di fallimento perché potrebbe disallinearsi, diventare obsoleto essendo
comunque una cosa a sé stante rispetto al codice che commenta.

Ci sono vari livelli di testo umano, non comprensibile dalle macchine
> (almeno non oggi, e speriamo mai), collegato ai programmi per computer.
> Si va dalle specifiche, alle descrizioni architetturali, alle specifiche
> delle API, alle docstring, ai commenti veri e propri.
>
> *Tutti* questi livelli sono *essenziali*. Per l'accennata insufficiente
> espressività dei linguaggi di programmazione, scrivere programmi è
> un'attività a perdita di conoscenza: il dettaglio delle operazioni
> comprensibili dalla macchina non conserva l'intenzione del programmatore.
>
> Ogni volta che si legge un programma privo di documentazione si effettua
> un'operazione costosa di "reverse intentioning", non dissimile dal
> "reverse engineering" ma ad un livello superiore.
>
> Scrivere codice corretto è difficile, scrivere codice espressivo lo è
> ancora di più, scrivere contemporaneamente codice espressivo e il testo
> che completi quell'espressività, inevitabilmente insufficiente, è
> difficilissimo e non gode della verifica automatica, da cui la tipica
> insofferenza dei programmatori, pigri per definizione.
>
> La necessaria manutenzione del codice comporta la manutenzione della sua
> descrizione testuale: ma senza quella descrizione, la stessa manutenzione
> è molto più costosa e pericolosa.
>

Concordo.

Siamo chiamati ad essere contemporaneamente meccanici, domatori,
> scrittori e poeti: non meraviglia che tendiamo ad alleggerire il
> fardello. Ahimè, non è una buona idea.
>

Qui meno :-)

Diciamo che io l'ho letta in maniera diversa. Il commento spesso diventa un
modo per non sforzarsi di tendere a del codice ben scritto ma per mettere
una toppa ("che schifo di roba ho scritto... potrei rifattorizzarla e
sistemarla meglio, ma faccio prima a scrivere un bel commento per dire
quello che dovrebbe fare questo guazzabuglio"). Di fronte a un
comportamento spesso come questo, diventa importante dare un segnale forte
riguardo al commento che è spesso un male.

Io almeno l'ho letta così.

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Agile programming Robert Martin

2014-10-06 Per discussione Nicola Larosa 
> Simone Federici wrote:
>> Ok vediamo un modulo più semplice 100 linee. Tu lo ritieni
>> sbagliato scrivere il commento nell'eccezione in fondo al modulo?
>> https://raw.githubusercontent.com/django/django/master/django/utils/tzinfo.py

Marco Beri wrote:
> Eh, eh... chiaramente no, non solo non è sbagliato secondo me, ma è
> pure utile.

Più che utile, lo ritengo indispensabile.


> Come sempre non esiste regola senza eccezioni

Nel libro Clean Code l'autore non ha proposto una regola, ma una sua
convinzione. Il suo giudizio sui commenti è complessivamente negativo, ma
piuttosto articolato e con parti positive, vedi l'incipit del cap. 4 a p.
53: "Nothing can be quite so helpful as a well-placed comment." e la
sezione "Good Comments" a p.55.


> Non direi certo che il commento del tuo esempio è una sconfitta del
> programmatore, ma venendo da un'epoca in cui il codice DOVEVA essere
> commentato,

Un'epoca? Il codice deve essere commentato e descritto anche oggi.


> la definizione seguente mi ha abbastanza colpito: "ogni commento non
> banale è un insuccesso del programmatore che non è riuscito a scrivere
> del codice auto-esplicativo".

Credo sia questa:

"Comments are, at best, a necessary evil. If our programming languages
were expressive enough, or if we had the talent to subtly wield those
languages to express our intent, we would not need comments very
much—perhaps not at all."

L'autore descrive in modo articolato pregi e difetti dei commenti; il suo
giudizio complessivo che sia un "male necessario" mi sembra miope.


Ci sono vari livelli di testo umano, non comprensibile dalle macchine
(almeno non oggi, e speriamo mai), collegato ai programmi per computer.
Si va dalle specifiche, alle descrizioni architetturali, alle specifiche
delle API, alle docstring, ai commenti veri e propri.

*Tutti* questi livelli sono *essenziali*. Per l'accennata insufficiente
espressività dei linguaggi di programmazione, scrivere programmi è
un'attività a perdita di conoscenza: il dettaglio delle operazioni
comprensibili dalla macchina non conserva l'intenzione del programmatore.

Ogni volta che si legge un programma privo di documentazione si effettua
un'operazione costosa di "reverse intentioning", non dissimile dal
"reverse engineering" ma ad un livello superiore.

Scrivere codice corretto è difficile, scrivere codice espressivo lo è
ancora di più, scrivere contemporaneamente codice espressivo e il testo
che completi quell'espressività, inevitabilmente insufficiente, è
difficilissimo e non gode della verifica automatica, da cui la tipica
insofferenza dei programmatori, pigri per definizione.

La necessaria manutenzione del codice comporta la manutenzione della sua
descrizione testuale: ma senza quella descrizione, la stessa manutenzione
è molto più costosa e pericolosa.

Siamo chiamati ad essere contemporaneamente meccanici, domatori,
scrittori e poeti: non meraviglia che tendiamo ad alleggerire il
fardello. Ahimè, non è una buona idea.

-- 
Nicola 'tekNico' Larosa 

The insight that _doing too much, too fast causes serious problems_,
is a core life truth that is gaining recognition in more and more fields
from neurology to psychotherapy to bodybuilding to personal relationships
to product design to engineering to project management to social systems
to basic science and philosophy to art to sex. - Johann Gevers, May 2014
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Agile programming Robert Martin

2014-10-06 Per discussione Marco Beri 
2014-10-05 11:12 GMT+02:00 Simone Federici :

> Ok vediamo un modulo più semplice 100 linee. Tu lo ritieni sbagliato
> scrivere il commento nell'eccezione in fondo al modulo?
>
> https://raw.githubusercontent.com/django/django/master/django/utils/tzinfo.py
>

Eh, eh... chiaramente no, non solo non è sbagliato secondo me, ma è pure
utile.

Come sempre non esiste regola senza eccezioni (tranne questa stessa... ma
allora è falsa... ma allora è vera... ecc.).

Non direi certo che il commento del tuo esempio è una sconfitta del
programmatore, ma venendo da un'epoca in cui il codice DOVEVA essere
commentato, la definizione seguente mi ha abbastanza colpito: "ogni
commento non banale è un insuccesso del programmatore che non è riuscito a
scrivere del codice auto-esplicativo".

Comunque il libro, a mio parere, merita di essere letto.

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python