Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Riccardo Magliocchetti]

Il 28/09/2015 21:43, Marco Paolini ha scritto:



Il giorno 27 settembre 2015 10:38, Riccardo Magliocchetti
> ha
scritto:

Ciao Marco,

Il 24/09/2015 13:55, Marco Paolini ha scritto:

I pythonisti in tutto il mondo hanno subito sintonizzato le antenne e in
questo
momento c'è un po' di fermento sui porting in python di queste 
tecnologie.
Alcuni riferimenti:

- https://github.com/dittos/graphqllib libreria per gestione request 
graphql
server-side
- https://github.com/syrusakbary/graphene una specie di rest-framework
per graphql
- https://github.com/elastic-coders/py-graphqlparser il porting cython
del parser

Io ci sto giocando da poche settimane e mi sembra essere un passo in 
avanti
significativo nell'ambto dei web services


Perchè? Nel backend usi js o python?

Uso python. Ultimamente stiamo mettendo su una architettura microservice che
prevede API gateway piccolissimo in node che fa il dispatch, dietro ci sono i
microservice python. Abbiamo copiato un po' da qua
https://www.nginx.com/blog/introduction-to-microservices/


link interessante grazie


La app node è utilissima per via dell'isomorfismo e perchè graphql è molto  +
avanti nel mondo js (per ora). Il backend python è forte per via della
standardizzazione django e dell'alta qualità delle 3rd party e perchè a me piace
di più.


grazie per gli spunti interessanti

--
Riccardo Magliocchetti
@rmistaken

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[enrico franchi]

2015-09-29 11:34 GMT+01:00 Marco Paolini :

Figurati. Aggiungo che l'isomorfismo è estremamente comodo in quanto per
> esempio il codice per la validazione di un modello può essere (in alcuni
> casi) condiviso tra client e server e quindi scrittto una sola volta.
> Questo tema sposta l'ago della bilancia a favore di javascript/nodejs come
> tecnologia per scrivere applicativi web.


Io tutt'ora fatico a trovare qualcosa che bilanci l'enorme svantaggio di
dovere usare javascript.

Il mondo di node.js mi sembra veramente rotto su piu' livelli. Intanto
vanno a velocita' forsennata nella creazione di tool (che ha piu' che
qualche implicazione nella creazione di servizi stabili). Un sacco di cose
che vengono fatte sono iniziate e poi abbandonate... sembra che abbiano
imparato l'arte del project manager dai peggio kiddies che facevano le
gemme per ruby.

L'idea stessa che sei asincrono, asincrono oppure asincrono e' sbagliata.
Ci sono task che sono semplicemente CPU bound. Le loro teorie su come
spezzettarli e' davvero roba che non dovrebbe essere esposta a livello
applicativo. E' perfino peggio di quello che succede con Python:
semplicemente dovere spostare a livello architetturale ogni problema di
codice e' bislacco. Con tutti i suoi difetti, perfino il modello di Java e'
piu' sensato.

Ma poi voglio dire... Javascript e' demenziale. Sono anni che cercano di
fare "alternative" a Javascript e qui si propone di muovere Javascript
anche dove non c'era... vedo qualcosa di contraddittorio. Saro' io.

No grazie... node.js mi sembra eleggere a paradigma tutti gli errori che
abbiamo visto nel mondo dello sviluppo javascript client side e in quello
Python e Ruby.


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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Riccardo Magliocchetti]

Il 29/09/2015 11:18, Marco Ippolito ha scritto:

Il 29 settembre 2015 08:41, Riccardo Magliocchetti
 ha scritto:


Uso python. Ultimamente stiamo mettendo su una architettura microservice
che
prevede API gateway piccolissimo in node che fa il dispatch, dietro ci
sono i
microservice python. Abbiamo copiato un po' da qua
https://www.nginx.com/blog/introduction-to-microservices/



link interessante grazie


C'è un libro molto interessante e fatto bene sui
microservices:"Building Microservices"-Sam Newman


Letto, piaciuto, fatta una lista degli altri libri consigliati dall'autore [1] 
:) Come panoramica sui microservices è molto utile, ti da una bella lista di 
cose che si complicano e a cui devi pensare se vuoi usare una architettura di 
questo genere.


[1] https://github.com/xrmx/buildingmicroservicesbook


--
Riccardo Magliocchetti
@rmistaken

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Ippolito]

>  ha scritto:

> Figurati. Aggiungo che l'isomorfismo è estremamente comodo in quanto per
> esempio il codice per la validazione di un modello può essere (in alcuni
> casi) condiviso tra client e server e quindi scrittto una sola volta. Questo
> tema sposta l'ago della bilancia a favore di javascript/nodejs come
> tecnologia per scrivere applicativi web. Inoltre ultimamente sono usciti due
> "porting" ancora non maturi di react su android e ios che si chiamano
> reactnative, questo permette di condividere codice anche all'interno delle
> app mobile *native*.

Queste cose, come ho avuto modo di dire altre volte, sono state dette,
ben anni fa, in un corso Stanford (Coursera)  tenuto da Balaji S.
Srinivasan, entrato l'anno scorso, nell'orbita di in uno dei più
importanti Venture Capitalist (Horowitz "Software is eating the
world").

La mia personale opinione che mi sono fatto nello scontrarmi con i
problemi che man mano mi sorgono in quello che sto facendo, è che ogni
linguaggio ha i suoi pro/contro.Per cui alla fine, bisogna sfruttare i
pro, mitigandone i contro con i pro degli altri linguaggi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Ippolito]

>> Il 29 settembre 2015 08:41, Riccardo Magliocchetti

> Letto, piaciuto, fatta una lista degli altri libri consigliati dall'autore
> [1] :) Come panoramica sui microservices è molto utile, ti da una bella
> lista di cose che si complicano e a cui devi pensare se vuoi usare una
> architettura di questo genere.
>
> [1] https://github.com/xrmx/buildingmicroservicesbook
>
Ottima lista. grazie!!!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Ippolito]

Il 29 settembre 2015 08:41, Riccardo Magliocchetti
 ha scritto:

>> Uso python. Ultimamente stiamo mettendo su una architettura microservice
>> che
>> prevede API gateway piccolissimo in node che fa il dispatch, dietro ci
>> sono i
>> microservice python. Abbiamo copiato un po' da qua
>> https://www.nginx.com/blog/introduction-to-microservices/
>
>
> link interessante grazie

C'è un libro molto interessante e fatto bene sui
microservices:"Building Microservices"-Sam Newman
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Paolini]

Il giorno 29 settembre 2015 08:41, Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> ha scritto:

> Il 28/09/2015 21:43, Marco Paolini ha scritto:
>
>>
>>
>> Il giorno 27 settembre 2015 10:38, Riccardo Magliocchetti
>>  riccardo.magliocche...@gmail.com>> ha
>> scritto:
>>
>> Ciao Marco,
>>
>> Il 24/09/2015 13:55, Marco Paolini ha scritto:
>>
>> I pythonisti in tutto il mondo hanno subito sintonizzato le
>> antenne e in
>> questo
>> momento c'è un po' di fermento sui porting in python di queste
>> tecnologie.
>> Alcuni riferimenti:
>>
>> - https://github.com/dittos/graphqllib libreria per gestione
>> request graphql
>> server-side
>> - https://github.com/syrusakbary/graphene una specie di
>> rest-framework
>> per graphql
>> - https://github.com/elastic-coders/py-graphqlparser il porting
>> cython
>> del parser
>>
>> Io ci sto giocando da poche settimane e mi sembra essere un passo
>> in avanti
>> significativo nell'ambto dei web services
>>
>>
>> Perchè? Nel backend usi js o python?
>>
>> Uso python. Ultimamente stiamo mettendo su una architettura microservice
>> che
>> prevede API gateway piccolissimo in node che fa il dispatch, dietro ci
>> sono i
>> microservice python. Abbiamo copiato un po' da qua
>> https://www.nginx.com/blog/introduction-to-microservices/
>>
>
> link interessante grazie
>
> La app node è utilissima per via dell'isomorfismo e perchè graphql è
>> molto  +
>> avanti nel mondo js (per ora). Il backend python è forte per via della
>> standardizzazione django e dell'alta qualità delle 3rd party e perchè a
>> me piace
>> di più.
>>
>
> grazie per gli spunti interessanti


Figurati. Aggiungo che l'isomorfismo è estremamente comodo in quanto per
esempio il codice per la validazione di un modello può essere (in alcuni
casi) condiviso tra client e server e quindi scrittto una sola volta.
Questo tema sposta l'ago della bilancia a favore di javascript/nodejs come
tecnologia per scrivere applicativi web. Inoltre ultimamente sono usciti
due "porting" ancora non maturi di react su android e ios che si chiamano
reactnative, questo permette di condividere codice anche all'interno delle
app mobile *native*.


>
> --
> Riccardo Magliocchetti
> @rmistaken
>
> http://menodizero.it
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Carlos Catucci]

2015-09-29 14:51 GMT+02:00 enrico franchi :

> Ma poi voglio dire... Javascript e' demenziale. Sono anni che cercano di
> fare "alternative" a Javascript e qui si propone di muovere Javascript
> anche dove non c'era... vedo qualcosa di contraddittorio. Saro' io.


Enrtico scusa ma quali alternative abbiamo a js (lato browser)? Ho visto
cento cosi ma non fanno altro che farti scrivere codice nel linguaggio X
che poi traducono in js.
Lo chiedo perche' mi piacerebbe avere alternative, anche se poi magari
dovessi scegliere js invece che l'alternativa in questione.
Al momento cerco di far far e le cose che mi servono a js con l'uso di
librerie. Adesso come adesso dovrei collaborare ad un progetto che usa Dojo
ad esempio, che non toccavo da versioni preistoriche ma mi sembra si sia
evoluto (se bene o male non posso ancora dirlo, sto guardandoci dentro,
quindi pareri illustri di chi ha avuto occasione sono graditi)

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

[Python] Presentazione

[Salvo Rapisarda]

Ciao,

mi chiamo Salvo Rapisarda e da un anno a questa parte mi sono avvicinato 
allo sviluppo nel linguaggio Python (che trovo fantastico!) e nel 
relativo web framework Django.


Ho deciso di imparare a programmare in Python grazie al fatto che ho 
utilizzato la piattaforma cloud OpenStack che è interamente scritta in 
questo linguaggio.


Dopo cosi' tanto tempo ho notato che esiste anche un community italiana 
su Python e quindi ho deciso di iscrivermi a questa mailing list.


Spero di essere il benvenuto! :)

Salvo.

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Paolini]

2015-09-29 21:52 GMT+02:00 Carlo Miron :

> 2015-09-29 20:00 GMT+02:00 Marco Paolini :
>
>
> > [...] soprattutto perchè per fare
> > il rendering della pagina single page app lato server hai *comunque*
> bisogno
> > di interprete javascript lato server.
>
> Uhm? In che senso? Puoi elaborare?
>

Una single page app angular per esempio, è composta da una pagina statica
mezza vuota (index.html) che popola il DOM iniziale e carica la app angular
stessa. Appena la app angualr prende il controllo crea dinamicamente lato
client tutti gli elementi del DOM necessari per visualizare correttamtnte
la pagina. Da questo momento in poi, angular ha preso il controllo e
gestisce autonomamente tutto, caricando risorse dal server se ne ha bisogno.

Questa sequenza appena descritta non è ottimale perchè prevede il
caricamento di una pagina "stub" dal server che e poi il caricamento
dell'intera app partendo in pratica da zero.

Per ottimizzare, il server nodejs (con l'aiiuto di vari framework e
librerie) lancia lato server la app angular alla prima visita, in modo da
tornare al browser un html che equivale alla pagina manipolata da angular a
loading completato.

Ah poi node serve per tutta la toolchain dello sviluppo frontend: da
package management (bower) alla fase di build (grunt) fino al testing.

Spero di essere stato chiaro, non sono un espertone

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Giovanni Porcari]

> Il giorno 30 set 2015, alle ore 00:02, Marco Paolini  
> ha scritto:
> 
> 
> 
> 2015-09-29 21:52 GMT+02:00 Carlo Miron :
>> 2015-09-29 20:00 GMT+02:00 Marco Paolini :
>> 
>> 
>> > [...] soprattutto perchè per fare
>> > il rendering della pagina single page app lato server hai *comunque* 
>> > bisogno
>> > di interprete javascript lato server.
>> 
>> Uhm? In che senso? Puoi elaborare?
> 
> Una single page app angular per esempio, è composta da una pagina statica 
> mezza vuota (index.html) che popola il DOM iniziale e carica la app angular 
> stessa. Appena la app angualr prende il controllo crea dinamicamente lato 
> client tutti gli elementi del DOM necessari per visualizare correttamtnte la 
> pagina. Da questo momento in poi, angular ha preso il controllo e gestisce 
> autonomamente tutto, caricando risorse dal server se ne ha bisogno.
> 
> Questa sequenza appena descritta non è ottimale perchè prevede il caricamento 
> di una pagina "stub" dal server che e poi il caricamento dell'intera app 
> partendo in pratica da zero.
> 
> Per ottimizzare, il server nodejs (con l'aiiuto di vari framework e librerie) 
> lancia lato server la app angular alla prima visita, in modo da tornare al 
> browser un html che equivale alla pagina manipolata da angular a loading 
> completato.
> 
> Ah poi node serve per tutta la toolchain dello sviluppo frontend: da package 
> management (bower) alla fase di build (grunt) fino al testing.
> 
> Spero di essere stato chiaro, non sono un espertone
> 

Abbastanza curioso come procedimento e in questo caso il server si fa carico di 
una parte di lavoro che sarebbe fattibile dal client con il vantaggio di 
distribuire questo lavoro sulle risorse di elaborazione dei client invece che 
affidare la renderizzazione al server. 

Non ne comprendo il vantaggio.  Inoltre lato server a mio avviso linguaggi come 
python sono più 'adatti' e non ti costringono a fare tutto asincrono come con 
node.js. 

Di javascript ne usiamo tanto ma se posso evitarmelo almeno sul server lo 
ritengo una benedizione ;)


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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[enrico franchi]

2015-09-29 15:47 GMT+01:00 Carlos Catucci :

> Enrtico scusa ma quali alternative abbiamo a js (lato browser)? Ho visto
> cento cosi ma non fanno altro che farti scrivere codice nel linguaggio X
> che poi traducono in js.


Oh, non abbiamo "alternative". Personalmente non mi sono trovato una
meraviglia con suddetti tool (linguaggio X -> Javascript). Nel senso che il
linguaggio X in generale mi piace piu' di Javascript, ma comunque alla fine
dei conti c'e' sempre il problema che trapela qua e la, che devi chiamare
librerie scritte in Javascript (e anche li, a volte ci sono pezzi di API
che potrebbero non avere un eccesso di senso senza un wrapper), se devi
debuggare hai due layer, se il customer ha un problema lui sta eseguendo
Javascript, ma tu hai scritto X e devi mappare le due cose insieme.

Il fatto che uno standard "a livello Javascript" si diffonda non e'
probabilissimo. Potrebbe passare da una larghissima adozione di suddetti
linguaggi (che a quel punto vengono a loro volta integrati)... ma
sinceramente non mi sembra eccessivamente probabile. Bisogna mettere
d'accordo gente come MS e Google. Bisogna capire come e se offrire
interoperabilita' fra le due tecnologie... mi sembra complicato.


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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[enrico franchi]

2015-09-29 18:43 GMT+01:00 Manlio Perillo :

> La portabilità?
>

Cosa intendi con "portabilita'"? Il senso "tradizionale" chiaramente non si
applica...


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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[enrico franchi]

2015-09-29 19:00 GMT+01:00 Marco Paolini :

> Quindi lo sviluppatore full-stack deve conoscere javascript. Viene
> naturale usare lo stesso linguaggio per l'intero stack, soprattutto perchè
> per fare il rendering della pagina single page app lato server hai
> *comunque* bisogno di interprete javascript lato server.
>

Si. Ma devono passare sul mio cadavere prima di mettere in produzione
node.js. Davvero.
Per ora non ho fatto eccessive storie per node.js in quanto dipendenza di
grunt, ma la cosa deve finire li.

Tra l'altro, io ho serissimi dubbi che questo approccio sia sempre
vincente. E' vero che guadagni il fatto di non spedire lo stub e hai un
loading piu' rapido della pagina. D'altra parte, appunto, hai spostato roba
lato server. Il che non e' un problema immenso (e' qualcosa che almeno a
livello parziale si vuole fare quasi sempre). Detto questo, non mi e'
davvero chiaro come scalare bene roba come Angular a livelli interessanti.
E, sfortunatamente, sara' colpa di troppe fatte male, ma tendo ad odiare le
single page apps.

Javascript è il primo linguaggio per popolarià su github.
>

Certo. Il secondo e' Java. Il quarto e' PHP. Quindi?

Tra l'altro la popolarita' di JS su Github si spiega piuttosto facilmente.
In primo luogo anche progetti non in Javascript potrebbero avere fette
considerevoli in Javascript. Questo da solo non basta, ma aiuta. In secondo
luogo e' una comunita' molto attiva (direi forsennata) che ogni due mesi
buoni butta fuori un nuovo aggeggio per ogni funzione o poco ci manca.



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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[enrico franchi]

2015-09-30 0:03 GMT+01:00 Giovanni Porcari :

> Abbastanza curioso come procedimento e in questo caso il server si fa
> carico di una parte di lavoro che sarebbe fattibile dal client con il
> vantaggio di distribuire questo lavoro sulle risorse di elaborazione dei
> client invece che affidare la renderizzazione al server.
>

Dipende molto dallo use-case, chiaramente, ma avere pezzi prefabbricati che
si possono servire aiuta, per lo meno, ad usare come si deve una CDN. Tra
l'altro, se hai un milione di richieste al secondo (ma anche 100K...) e
queste richieste sono "servimi una pagina", hai un problema (pure
relativamente banale se la pagina e' statica).

Se invece questa pagina per funzionare fa altre 10 chiamate http (che e'
pure poco, per certi versi)... beh, ecco che devi metterti in testa che
devi gestire 10M richieste al secondo. E ogni frontendista che salta su con
il suo widget che si fa le sue 2-3 chiamate diventa un costo insostenibile.




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

Re: [Python] Presentazione

[Giovanni Porcari]

> Il giorno 29/set/2015, alle ore 18:42, Salvo Rapisarda  
> ha scritto:
> 
> Ciao,
> 
> mi chiamo Salvo Rapisarda e da un anno a questa parte mi sono avvicinato allo 
> sviluppo nel linguaggio Python (che trovo fantastico!) e nel relativo web 
> framework Django.
> 
> Ho deciso di imparare a programmare in Python grazie al fatto che ho 
> utilizzato la piattaforma cloud OpenStack che è interamente scritta in questo 
> linguaggio.
> 
> Dopo cosi' tanto tempo ho notato che esiste anche un community italiana su 
> Python e quindi ho deciso di iscrivermi a questa mailing list.
> 
> Spero di essere il benvenuto! :)
> 
> Salvo.
> 
> 

Ciao Salvo e benvenuto :)

G

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Paolini]

Il giorno 29 settembre 2015 19:43, Manlio Perillo 
ha scritto:

> 2015-09-29 14:51 GMT+02:00 enrico franchi :
>
>>
>> 2015-09-29 11:34 GMT+01:00 Marco Paolini :
>>
>> Figurati. Aggiungo che l'isomorfismo è estremamente comodo in quanto per
>>> esempio il codice per la validazione di un modello può essere (in alcuni
>>> casi) condiviso tra client e server e quindi scrittto una sola volta.
>>> Questo tema sposta l'ago della bilancia a favore di javascript/nodejs come
>>> tecnologia per scrivere applicativi web.
>>
>>
>> Io tutt'ora fatico a trovare qualcosa che bilanci l'enorme svantaggio di
>> dovere usare javascript.
>>
>
> > [...]
>
> La portabilità?
>
> Il web è l'unico campo dove esistono standard che sono seguiti da tutti i
> maggiori protagonisti.
> Lato desktop la situazione è pessima. Ignorando la GUI, anche voler usare
> OpenGL ES significa avere problemi dato che Windows
> non lo supporta.
>
> Una volta che hai un linguaggio che semplicemente *funziona*, sembra sia
> una conseguenza naturale che lo usano tutti.
>

Si esattamente Manlio. Lato browser javascript è il linguaggio e basta. I
vari coffescript o dart (che poi ovviemente compilano in js) sono delle
nicchie molto piccole e un po' in disuso. Javascript si usa anche per le
applicazioni "native" desktop (per esempio il client di slack credo sia in
javascript) anche se non so bene quanto sia diffuso li.

Quindi lo sviluppatore full-stack deve conoscere javascript. Viene naturale
usare lo stesso linguaggio per l'intero stack, soprattutto perchè per fare
il rendering della pagina single page app lato server hai *comunque*
bisogno di interprete javascript lato server.

Javascript è il primo linguaggio per popolarià su github. Anche python è
molto popolare! http://githut.info/

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Carlo Miron]

2015-09-29 20:00 GMT+02:00 Marco Paolini :


> [...] soprattutto perchè per fare
> il rendering della pagina single page app lato server hai *comunque* bisogno
> di interprete javascript lato server.

Uhm? In che senso? Puoi elaborare?

㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Presentazione

[Paolo Melchiorre]

Benvenuto!

Il giorno Mar 29 Set 2015 19:19 Giovanni Porcari <
giovanni.porc...@softwell.it> ha scritto:

>
> > Il giorno 29/set/2015, alle ore 18:42, Salvo Rapisarda <
> salvor...@yahoo.it> ha scritto:
> >
> > Ciao,
> >
> > mi chiamo Salvo Rapisarda e da un anno a questa parte mi sono avvicinato
> allo sviluppo nel linguaggio Python (che trovo fantastico!) e nel relativo
> web framework Django.
> >
> > Ho deciso di imparare a programmare in Python grazie al fatto che ho
> utilizzato la piattaforma cloud OpenStack che è interamente scritta in
> questo linguaggio.
> >
> > Dopo cosi' tanto tempo ho notato che esiste anche un community italiana
> su Python e quindi ho deciso di iscrivermi a questa mailing list.
> >
> > Spero di essere il benvenuto! :)
> >
> > Salvo.
> >
> >
>
> Ciao Salvo e benvenuto :)
>
> G
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python