Re: [Python] FRP book (era: Re: Web Server e Web Framework)
On Fri, Jul 3, 2015 at 5:19 PM, Nicola Larosa n...@teknico.net wrote: Nicola Larosa wrote: Functional Reactive Programming http://www.manning.com/blackheath/ Marco Beri wrote: Ohibò! Ma tu non eri contro le cose stateful a priori? Esatto. It can be seen as a complete embedded language for stateful logic :-) Continua a leggere, non fermarti a una frase. :-) Infatti ci sono già arrivato ;-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] FRP book (era: Re: Web Server e Web Framework)
Marco Beri wrote: Comunque, aldilà o meno, spererei di vedere qualcosa di diverso nel nostro lavoro, prima di arrivare a quel punto fatidico. Intendo come modalità di sviluppo. Non per il gusto della novità fine a se stessa, ma per quella vaga sensazione di esser circondati di problemi di base irrisolti, nevvero? :-) Potresti fare di peggio che leggere il primo capitolo (gratis) di questo: Functional Reactive Programming http://www.manning.com/blackheath/ Magari non ti riconosci nelle soluzioni, ma nei problemi scommetto di sì. -- Nicola 'tekNico' Larosa http://www.tekNico.net/ ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] FRP book (era: Re: Web Server e Web Framework)
Nicola Larosa wrote: Functional Reactive Programming http://www.manning.com/blackheath/ Marco Beri wrote: Ohibò! Ma tu non eri contro le cose stateful a priori? Esatto. It can be seen as a complete embedded language for stateful logic :-) Continua a leggere, non fermarti a una frase. :-) -- Nicola 'tekNico' Larosa http://www.tekNico.net/ ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Why Go is not good
2015-07-02 22:54 GMT+01:00 Enrico Bianchi enrico.bian...@ymail.com: Lo posto piu` che altro per ribilanciare i discorsi su Go e su Python visti sul gruppo ;) http://yager.io/programming/go.html Riassunto: Go is not Haskell/SML. No shit, Sherlock! Ci sono alcuni punti in cui ha indubbiamente ragione. Ma il linguaggio davvero inattaccabile io non lo ho visto. Io credo che Go sia molto consistente nelle promesse che fa e come le delivera. I suoi limiti sono quasi tutti chiari dopo una settimana che uno ci lavora. Quando non sono accettabili, prendere altro e fine della fiera. Dal mio canto, posso dire che per alcuni punti mi trovo concorde, inoltre essendomi scontrato con questo, direi che i miei dubbi sono molto piu` radicati: https://blog.cloudflare.com/go-crypto-bridging-the-performance-gap/ Scusa, io quell'articolo non lo ho capito. Nel senso che dovrebbe parlare delle performance di Go (apparentemente da questo thread), ma in realta' si mette a spiegare roba sui cripto-sistemi. Che va benissimo, ma non ho esattamente capito in che modo e' rilevante. Da quello che ho capito la storia breve e': le implementazioni di un po' di cose rilevanti nella stdlib di Go sono lente, noi abbiamo fatto una versione piu' veloce e stiamo cercando di integrarla nella libreria standard. Ok. Credo che lo stesso si possa dire della stdlib di quasi ogni linguaggio di programmazione, per vari motivi (ottimizzazione per il caso medio, mancanza di risorse, errore di API iniziale, non ci possiamo fare niente perche' la piattaforma e' lenta per i cazzi suoi). -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] FRP book (era: Re: Web Server e Web Framework)
Il giorno 03/lug/2015, alle ore 15:43, Nicola Larosa n...@teknico.net ha scritto: Functional Reactive Programming http://www.manning.com/blackheath/ Magari non ti riconosci nelle soluzioni, ma nei problemi scommetto di sì. Caro Nicola ci ho dato una scorsa veloce e devo dire che mi sono molto stupito di vedere descritta la tecnica di procedere a ‘definire’ il problema invece di dare l’algoritmo. Stupito e rallegrato. Tanti e tanti anni or sono, quando ancora ero un giovanotto di belle speranze, avevo favoleggiato di creare un linguaggio che avevo denominato nella mai mente ‘definitivo’ alludendo al fatto che sarebbe stato per definizioni successive e volte a dare una descrizione sempre più analitica del problema ma anche che sarebbe stata la soluzione ‘definitiva’ ai problemi di programmazione. Mi ricordo che mi piaceva immaginare di poter dire ‘devo fare una fattura’ 'una fattura è una testata con righe' 'una testata è composta dai dati del cliente dai riferimenti e dai totali' 'i dati del cliente sono la ragione sociale, l’indirizzo… ecc' e via discorrendo. Ovviamente non avevo la competenza per scrivere una cosa del genere e le macchine dell’epoca probabilmente non avrebbero potuto nemmeno reggere la cosa. Ma a livello di esercizio mentale mi arrovellavo a pensare la possibile sintassi. Per questo ti ringrazio del link e sarò curioso di vedere come poi è stato realizzato quello che per me era solo un sogno senza speranza :D G ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Why Go is not good
2015-07-03 15:04 GMT+02:00 enrico franchi enrico.fran...@gmail.com: Ma il linguaggio davvero inattaccabile io non lo ho visto Ti sbagli, prova a contestare qualcosa di un applicativo scritto in monicelli e vediamo come ne esci dopo una supercazzora ;) Carlos -- EZLN ... Para Todos Todo ... Nada para nosotros ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Why Go is not good
2015-07-02 23:40 GMT+01:00 Enrico Bianchi enrico.bian...@ymail.com: Beh, diciamo che l'override dei metodi (o meglio, delle funzioni) mi avrebbe fatto comodo in alcuni casi Parli di override o di overload? Perche' parlare di override delle funzioni non ha alcun senso (visto che si parla di override in qualche tipo di contesto OO, altrimenti non puoi manco esprimere il concetto). , cosi` come la gestione delle eccezioni (no, error da solo non mi e` molto utile, intendo proprio try/catch come in python o in java). Credo che tu non abbia chiara la gestione degli errori in Go. In primo luogo, per i rarissimi casi in cui veramente hai bisogno della semantica completa delle eccezioni (o meglio, della versione castrata che e' implementata nei vari Python, Java, C++ e combriccola con cui sei probabilmente familiare) puoi usare panic. E a chiunque ti stai facendo una CR e' chiaro che o sei in uno dei pochi casi in cui vuoi usarlo per il controllo di flusso (vedi gli esempi nella stdlib di Go) oppure effettivamente sei nel caso soccia e qui che ci faccio, flippo il tavolo e vado a casa. Poi magari qualcuno unflippa il tavolo e va avanti, ma davvero non avevi alternativa. Io personalmente trovo che la gestione degli errori di Go rende il codice complessivamente molto piu' snello. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] FRP book (era: Re: Web Server e Web Framework)
2015-07-03 15:43 GMT+02:00 Nicola Larosa n...@teknico.net: Marco Beri wrote: Comunque, aldilà o meno, spererei di vedere qualcosa di diverso nel nostro lavoro, prima di arrivare a quel punto fatidico. Intendo come modalità di sviluppo. Non per il gusto della novità fine a se stessa, ma per quella vaga sensazione di esser circondati di problemi di base irrisolti, nevvero? :-) Potresti fare di peggio che leggere il primo capitolo (gratis) di questo: Functional Reactive Programming http://www.manning.com/blackheath/ Magari non ti riconosci nelle soluzioni, ma nei problemi scommetto di sì. Aggiunto in lista to-read. Thanks. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] FRP book (era: Re: Web Server e Web Framework)
2015-07-03 15:43 GMT+02:00 Nicola Larosa n...@teknico.net: Functional Reactive Programming http://www.manning.com/blackheath/ Ohibò! Ma tu non eri contro le cose stateful a priori? It can be seen as a complete embedded language for stateful logic :-) Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] PyQt vs PySide
2015-07-03 8:55 GMT+01:00 Kbyte kb...@snowpenguin.org: Sul wiki delle QT ho letto un po' di informazioni su PySide. Io però mi chiedo, questo binding è effettivamente sviluppato o è sulla via della morte? Attualmente mi capita di sviluppare con QT5 + Python3 e già sarei tagliato fuori, però sono sempre attento a nuove possibilità :P Per vari motivi io preferirei usare PySide, ma onestamente mi sembra che quelli di Qt non si siano mai cagati troppo Python... E PySide non mi sembra affatto in buono stato, almeno l'ultima volta che ho guardato. Anche io uso Qt5 + Python 3 e non ho avuto molta scelta. Se non hai problemi di licenza, che alla fine è l'unico problema grosso di PyQt (è GPL e quindi se la usi anche il tuo software deve essere GPL), allora vai pure con quello. Ciauz ~Ale ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Alternativa snella a virtualenv: PYTHONUSERBASE
Il presupposto iniziale che virtualenv sia complicato o sovradimensionato per un normale uso non rispecchia il mio normale utilizzo. Con virtualenvwrapper gestisco facilmente i miei progetti con diversi virtualenv, ho il codice versionato da un lato e posso alternativamente avere vari virtualenv con versioni differenti dei miei pacchetti da provare o versioni differenti di python. La lettura e' stata istruttiva ma la soluzione mi sembra piu' complicata e meno potente. Paolo Il giorno ven 3 lug 2015 alle ore 09:09 Kbyte kb...@snowpenguin.org ha scritto: A qualcuno potrebbe venire l'orticaria nel lanciare pip freeze e leggere le dipendenze del SO, non strettamente necessarie al progetto, ma a parte questo non ci vedo particolari controidicazioni. Nella mia esperienza mi darebbe più problemi che altro. Posso capire macchine dove le app in deploy fanno parte tutte di uno stesso sistema per cui le librerie (di sistema) che devi usare sono le stesse. Ma nella maggior parte dei casi ti trovi a deployare applicazioni diverse, che non devono parlarsi e che fanno uso di librerie particolari, se non nel nome nella versione utilizzata. Con quella soluzione se si ci affida alla lib installata nel SO e per qualche motivo il SO l'aggiorna, credo che qualche pericolo di vedere qualcosa non funzionare più sia reale. ___ 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] Alternativa snella a virtualenv: PYTHONUSERBASE
A qualcuno potrebbe venire l'orticaria nel lanciare pip freeze e leggere le dipendenze del SO, non strettamente necessarie al progetto, ma a parte questo non ci vedo particolari controidicazioni. Nella mia esperienza mi darebbe più problemi che altro. Posso capire macchine dove le app in deploy fanno parte tutte di uno stesso sistema per cui le librerie (di sistema) che devi usare sono le stesse. Ma nella maggior parte dei casi ti trovi a deployare applicazioni diverse, che non devono parlarsi e che fanno uso di librerie particolari, se non nel nome nella versione utilizzata. Con quella soluzione se si ci affida alla lib installata nel SO e per qualche motivo il SO l'aggiorna, credo che qualche pericolo di vedere qualcosa non funzionare più sia reale. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Web Server e Web Framework
Ciao Ragazzi,non mi è chiaro il confine tra Web Server e Web Framework, ovvero di cosa si occupa l'uno e l'altro e quindi dove finisce uno e comincia l'altro. Sviluppando nei vari django/Flask si utilizza il Webserver fornito che è adatto solo al test e viene sempre sottolineato di non utilizzarlo mai in produzione.Quindi devo sempre appoggiarmi ad Apache o a qualche altro WebServer (che alternative ci sono con Python?).GraziePiergiorgio___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] PyQt vs PySide
Sul wiki delle QT ho letto un po' di informazioni su PySide. Io però mi chiedo, questo binding è effettivamente sviluppato o è sulla via della morte? Attualmente mi capita di sviluppare con QT5 + Python3 e già sarei tagliato fuori, però sono sempre attento a nuove possibilità :P ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Web Server e Web Framework
Il 03/07/2015 09:09, piergiorgio pancino ha scritto: Ciao Ragazzi, non mi è chiaro il confine tra Web Server e Web Framework, ovvero di cosa si occupa l'uno e l'altro e quindi dove finisce uno e comincia l'altro. Il Webserver e' il programma (demone) che e' in ascolto su una porta ed attende connessioni e richieste; quando arriva una richiesta fa qualcosa, tipicamente restituisce una pagina html. La pagina html servita dal webserver puo' essere una pagina statica (un file gia' scritto e pronto per essere renderizzato) oppure puo' essere, diciamo, creato al volo; il programma che crea questo contenuto html dinamico e' la tua applicazione web. Il Web Framework e' un insieme di librerie che ti aiuta a creare un'applicazione web; alcuni lo paragonano ad un tavolo da lavoro completo di utensili. Sviluppando nei vari django/Flask si utilizza il Webserver fornito che è adatto solo al test e viene sempre sottolineato di non utilizzarlo mai in produzione. In una piccola LAN (che dovrebbe essere sicura) lo puoi anche usare. Quindi devo sempre appoggiarmi ad Apache o a qualche altro WebServer (che alternative ci sono con Python?). Yes; con python puoi utilizzare anche Apache (ci sono vari metodi); ho letto anche di gunicorn scritto in python, ma non l'ho mai provato. Ciao diego ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Web Server e Web Framework
2015-07-03 10:15 GMT+02:00 Diego Barrera diegonebarr...@yahoo.it: Il 03/07/2015 09:09, piergiorgio pancino ha scritto: Sviluppando nei vari django/Flask si utilizza il Webserver fornito che è adatto solo al test e viene sempre sottolineato di non utilizzarlo mai in produzione. In una piccola LAN (che dovrebbe essere sicura) lo puoi anche usare. Io direi nemmeno lì. È mono processo e non efficiente. Quindi devo sempre appoggiarmi ad Apache o a qualche altro WebServer (che alternative ci sono con Python?). Yes; con python puoi utilizzare anche Apache (ci sono vari metodi); ho letto anche di gunicorn scritto in python, ma non l'ho mai provato. uwsgi tutta la vita. Ciao. Marco. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro http://beri.it/articoli/ - Qualche articolo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Why Go is not good
2015-07-02 23:54 GMT+02:00 Enrico Bianchi enrico.bian...@ymail.com: Lo posto piu` che altro per ribilanciare i discorsi su Go e su Python visti sul gruppo ;) http://yager.io/programming/go.html Dal mio canto, posso dire che per alcuni punti mi trovo concorde, Go è nato con un motivo ben preciso (personale interpretazione): gli autori del linguaggio erano stufi di avere a che fare con linguaggi di programmazione complessi che però causano infiniti problemi in fase di sviluppo da parte di grossi team ed in fase di manutenzione. Tutta la filosofia ed il disegno di Go rispecchiano questo punto di partenza (tra l'altro esasperata dal fatto che gli autori lavorano in Google e su una grossa base di codice in C++). Tra l'altro il problema è reale, perchè io ne sono afflitto *anche* con Python, ogni volta che devo lavorare su una base di codice scritta da altri. Riguardo l'articolo, poi, l'autore dimentica che Go ha il package unsafe. Di certo Go ha dei problemi, ma non sono quelli elencati dall'autore dell'articolo e sono per lo più problemi di implementazione. Una cosa che forse manca in Go sono le tagged union, perchè le interfacce sono effettivamente un pò abusate e non permettono il controllo dell'allocazione della memoria. Spero solo che nei prossimi 20 anni i nuovi linguaggi sapranno cogliere questà innovazione portata da Go. [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Web Server e Web Framework
Il giorno 03/lug/2015, alle ore 10:17, Marco Beri marcob...@gmail.com ha scritto: 2015-07-03 10:15 GMT+02:00 Diego Barrera diegonebarr...@yahoo.it: Il 03/07/2015 09:09, piergiorgio pancino ha scritto: Sviluppando nei vari django/Flask si utilizza il Webserver fornito che è adatto solo al test e viene sempre sottolineato di non utilizzarlo mai in produzione. In una piccola LAN (che dovrebbe essere sicura) lo puoi anche usare. Io direi nemmeno lì. È mono processo e non efficiente. Quindi devo sempre appoggiarmi ad Apache o a qualche altro WebServer (che alternative ci sono con Python?). Yes; con python puoi utilizzare anche Apache (ci sono vari metodi); ho letto anche di gunicorn scritto in python, ma non l'ho mai provato. uwsgi tutta la vita. Siccome sono un po’ più credente di Marco posso dire uwsgi per tutta la vita e anche nell’aldilà :D G ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Web Server e Web Framework
2015-07-03 11:17 GMT+02:00 Giovanni Porcari giovanni.porc...@softwell.it: Il giorno 03/lug/2015, alle ore 10:17, Marco Beri marcob...@gmail.com ha scritto: uwsgi tutta la vita. Siccome sono un po’ più credente di Marco posso dire uwsgi per tutta la vita e anche nell’aldilà :D :-)) Comunque, aldilà o meno, spererei di vedere qualcosa di diverso nel nostro lavoro, prima di arrivare a quel punto fatidico. Intendo come modalità di sviluppo. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro http://beri.it/articoli/ - Qualche articolo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Web Server e Web Framework
Il giorno 03/lug/2015, alle ore 11:44, Marco Beri marcob...@gmail.com ha scritto: 2015-07-03 11:17 GMT+02:00 Giovanni Porcari giovanni.porc...@softwell.it: Il giorno 03/lug/2015, alle ore 10:17, Marco Beri marcob...@gmail.com ha scritto: uwsgi tutta la vita. Siccome sono un po’ più credente di Marco posso dire uwsgi per tutta la vita e anche nell’aldilà :D :-)) Comunque, aldilà o meno, spererei di vedere qualcosa di diverso nel nostro lavoro, prima di arrivare a quel punto fatidico. Intendo come modalità di sviluppo. troll_mode In realtà il profeta di una modalità di sviluppo ti è anche venuto a trovare. Ma non lo hai riconosciuto… Forse per i baffi ;) /troll_mode G. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
