2015-03-25 10:10 GMT+01:00 Nicola Larosa n...@teknico.net:
(Coppini in bagno e poliamore nello stesso messaggio mi lasciano
lievemente perplesso.)
Io sarei piu' ... preoccupato che perplesso ;)
Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
2015-03-25 10:16 GMT+01:00 Nicola Larosa n...@teknico.net:
Perché sei ancora preda di una morale bigotta e repressiva. ;-)
Magari hai ragione tu Nicola. ;)
Peace Love
Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing
Il 24/03/2015 21:15, Carlos Catucci ha scritto:
https://www.paypal-engineering.com/2014/12/10/10-myths-of-enterprise-python/
Myth #8
Mi era parso di capire che ci sono dati per dire che il problema e' reale
ed e' una delle cose che sta spingendo alcuni verso Go.
Roberto De Ioris wrote:
Se vieni a firenze saro' la tua ombra, anche in bagno, appena dici
una frase sbagliata ti do' un coppino e ti correggo. Dannato
pignolo...
Purtroppo (o per fortuna ;-) ) non ci vengo.
Ah, ho aggiunto un puntino alla fine della tua frase, spero non ti
scocci. ;-D
2015-03-25 9:17 GMT+01:00 Roberto De Ioris robe...@unbit.it:
Il non dover scegliere e' un grande vantaggio (ed e' anche una cosa molto
pythonica).
Cerrtto. Io sto dando una occhiata al tutorial introduttivo. E trovo subito
che puoi dichiarare le variabili in due modi differenti, di cui uno
Roberto De Ioris ha scritto:
Node e Go hanno deciso che basta un solo engine/approccio, il
primo ti dice che con la programmazione a callback fai tutto
(e vabbe' qui si apre un mondo [di bestemmie])
Esattamente. :-D
il secondo che i thread in userspace (passatemi il termine)
sono la cosa
Il 24/03/2015 21:15, Carlos Catucci ha scritto:
https://www.paypal-engineering.com/2014/12/10/10-myths-of-enterprise-python/
Myth #8
Mi era parso di capire che ci sono dati per dire che il problema e' reale
ed e' una delle cose che sta spingendo alcuni verso Go.
Hmm, python HA una
Il 25 marzo 2015 09:17, Roberto De Ioris robe...@unbit.it ha scritto:
Mi era parso di capire che ci sono dati per dire che il problema e' reale
ed e' una delle cose che sta spingendo alcuni verso Go.
Hmm, python HA una marea di engine di concorrenza, e alcuni di altissimo
livello e davvero
Il 25 marzo 2015 09:17, Roberto De Ioris robe...@unbit.it ha scritto:
Mi era parso di capire che ci sono dati per dire che il problema e'
reale
ed e' una delle cose che sta spingendo alcuni verso Go.
Hmm, python HA una marea di engine di concorrenza, e alcuni di altissimo
livello e
Roberto De Ioris ha scritto:
Node e Go hanno deciso che basta un solo engine/approccio, il
primo ti dice che con la programmazione a callback fai tutto
(e vabbe' qui si apre un mondo [di bestemmie])
Esattamente. :-D
il secondo che i thread in userspace (passatemi il termine)
sono la
Roberto De Ioris wrote:
Se vieni a firenze saro' la tua ombra, anche in bagno, appena dici
una frase sbagliata ti do' un coppino e ti correggo. Dannato
pignolo...
Purtroppo (o per fortuna ;-) ) non ci vengo.
Ah, ho aggiunto un puntino alla fine della tua frase, spero non ti
scocci. ;-D
On Mar 25, 2015 9:45 AM, Carlo Miron mi...@python.it wrote:
Il 25 marzo 2015 09:17, Roberto De Ioris robe...@unbit.it ha scritto:
Mi era parso di capire che ci sono dati per dire che il problema e'
reale
ed e' una delle cose che sta spingendo alcuni verso Go.
Hmm, python HA una marea di
Nicola Larosa ha scritto:
(Coppini in bagno e poliamore nello stesso messaggio mi lasciano
lievemente perplesso.)
Roberto De Ioris ha scritto:
dannazione. punto tuo.
Certe cose vanno accettate, reprimersi fa male. :-)
Carlos Catucci ha scritto
Io sarei piu' ... preoccupato che perplesso
2015-03-25 10:11 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com:
https://xkcd.com/927/
Vecchia ma sempre attuale. D'altronde non era Tanebaum che diceva di Unix
che il suo bello e' che e' uno standard e quindi ciascun produttore si era
fatto il suo personale di standard?
Carlos
--
EZLN
On 03/25/2015 09:20 AM, Diego Barrera wrote:
Myth #8
Mi era parso di capire che ci sono dati per dire che il problema e' reale
ed e' una delle cose che sta spingendo alcuni verso Go.
Oddio, io mi sto spingendo verso Go anche per una questione di
efficienza di memoria (ok, e` un argomento
2015-03-25 10:28 GMT+01:00 Carlos Catucci carlos.catu...@gmail.com:
On 25 March 2015 at 10:22, Nicola Larosa n...@teknico.net wrote:
L'operatore := combina dichiarazione (var) ed inizializzazione:
Si ma mi chiedo: serve davvero?
Anche a me la doppia scelta non piace, ma quella corta
2015-03-25 10:54 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com:
Se leggi la specifica del linguaggio noterai che c'è anche un altra
importante differenza tra var e `:=`
Forse ancora non ci arrivo. Resta il fatto che la scelta mi appare strana,
per ignoranza, sia chiaro.
Carlos
--
EZLN
Carlos Catucci wrote:
puoi dichiarare le variabili in due modi differenti,
di cui uno con il costrutto :=
L'operatore := combina dichiarazione (var) ed inizializzazione:
On declaring variables
http://dave.cheney.net/2014/05/24/on-declaring-variables
--
Nicola 'tekNico' Larosa
Il giorno 25/mar/2015, alle ore 10:10, Nicola Larosa n...@teknico.net ha
scritto:
Pace e poliamore...
Pace e poliamore sempre.
(Coppini in bagno e poliamore nello stesso messaggio mi lasciano
lievemente perplesso.)
onestamente, il thread ha preso un'altra piega. Preoccupante piu'
Explicit is better than implicit.
Il giorno 25 marzo 2015 11:16, Carlos Catucci carlos.catu...@gmail.com ha
scritto:
2015-03-25 10:54 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com:
Se leggi la specifica del linguaggio noterai che c'è anche un altra
importante differenza tra var e `:=`
On 25 March 2015 at 10:22, Nicola Larosa n...@teknico.net wrote:
L'operatore := combina dichiarazione (var) ed inizializzazione:
Si ma mi chiedo: serve davvero? In javascript [non devo parlare di Python,
non devo parlare di Python, non devo parlare di Python, ..., non devo
parlare di Python]
enrico franchi wrote:
In realta' il comportamento che descrivi e' l'implementazione della
versione principale di go. Nella specifica, non dice niente su M -
N. Dice solo che viene chiamata as an independent concurrent thread
of control.
Grazie, m'era sfuggito.
E in effetti gccgo,
Roberto De Ioris:
Quello che descrivi te mi sembra parecchio rocambolesco (continuo
context switch tra thread dedicati all'i/o e tread puramente cpu-centrici),
ma se e' davvero cosi', tanto di cappello :)
hai raggione la maggior parte delle implementazioni si limitano
come hai detto tu fare
Nicola Larosa n...@teknico.net:
Impatta la scalabilità. Usare un thread per ogni operazione
concorrente significa esser limitati a qualche migliaio di esecuzioni
contemporanee, con alti consumi di memoria.
Per arrivare a milioni di connessioni contemporanee bisogna usare approcci
più come
Nicola Larosa n...@teknico.net:
Impatta la scalabilità. Usare un thread per ogni operazione
concorrente significa esser limitati a qualche migliaio di esecuzioni
contemporanee, con alti consumi di memoria.
Per arrivare a milioni di connessioni contemporanee bisogna usare
approcci
più
On Wednesday 25 March 2015 11:50:17 Nicola Larosa wrote:
Pochi programmatori apprezzano il genio dell'indentazione significativa:
sarebbe stato un problema per l'adozione del linguaggio, ancor più dello
svantaggio di non poter avere funzioni anonime inline.
Però una cosa che mi ha
Il giorno 25 marzo 2015 11:50, Nicola Larosa n...@teknico.net ha scritto:
Simone Federici wrote:
{
ma quanto mi disturbano le parentesi...
}
Eh, ormai ci ho rifatto il callo.
Pochi programmatori apprezzano il genio dell'indentazione significativa:
sarebbe stato un problema per
2015-03-25 11:13 GMT+00:00 Nicola Larosa n...@teknico.net:
Impatta la scalabilità. Usare un thread per ogni operazione concorrente
significa esser limitati a qualche migliaio di esecuzioni contemporanee,
con alti consumi di memoria.
E non a caso e' da un po' che anche i Javisti hanno smesso
2015-03-25 11:55 GMT+00:00 Manlio Perillo manlio.peri...@gmail.com:
Costa di più, in termini monetari.
Non solo: e' anche molto piu' complesso calcolare l'availability.
--
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
2015-03-25 12:36 GMT+00:00 Roberto De Ioris robe...@unbit.it:
Nel 4.9 sono stati introdotti gli split stack (feature belissima, che gia'
ho avuto occasione di usare in altri contesti) il che ha avvicinato le
goroutine di gccgo a go.
Ma sbaglio o gli split-stack girano solo su Linux?
--
.
2015-03-25 12:36 GMT+00:00 Roberto De Ioris robe...@unbit.it:
Nel 4.9 sono stati introdotti gli split stack (feature belissima, che
gia'
ho avuto occasione di usare in altri contesti) il che ha avvicinato le
goroutine di gccgo a go.
Ma sbaglio o gli split-stack girano solo su Linux?
On Wed, Mar 25, 2015 at 10:58 AM, Nicola Larosa n...@teknico.net wrote:
E in effetti gccgo, l'ultima volta che ho controllato, le mappava 1:1
sui thread dell'OS.
Sul serio?!? È sufficiente per impedirne l'uso in molti casi. :-(
Non ho trovato conferma nella documentazione ufficiale, ma ne
2015-03-25 11:17 GMT+00:00 Carlos Catucci carlos.catu...@gmail.com:
E questo, se ho ben capito, con python si fa con molta fatica.
Molta... e' relativo. Diciamo che in generale scrivere sistemi I/O bound
ad alte performance in Python rimane abbastanza facile.
In generale sai anche di partenza
On Wed, Mar 25, 2015 at 11:58 AM, Nicola Larosa n...@teknico.net wrote:
[...]
E in effetti gccgo, l'ultima volta che ho controllato, le mappava 1:1
sui thread dell'OS.
Sul serio?!? È sufficiente per impedirne l'uso in molti casi. :-(
Spero gccgo passi a usare il runtime principale, e
Nicola Larosa wrote:
Avere un thread di sistema per ogni goroutine taglia le gambe.
Carlos Catucci wrote:
E questo, se ho ben capito, con python si fa con molta fatica.
Si fa con l'approccio asincrono: Twisted, Tornado, o asyncio.
Altra domanda, so che Django, ad esempio, e' usato in siti
Nicola Larosa wrote:
Spero gccgo passi a usare il runtime principale, e presto.
Manlio Perillo wrote:
Se lo facesse, sarebbe un problema, IMHO.
Il runtime principale è la causa della non interoperabilità
con il resto del mondo, AFAIK.
La non-interoperabilità è unidirezionale.
Puoi
On Wed, Mar 25, 2015 at 12:37 PM, Nicola Larosa n...@teknico.net wrote:
Nicola Larosa wrote:
Spero gccgo passi a usare il runtime principale, e presto.
Manlio Perillo wrote:
Se lo facesse, sarebbe un problema, IMHO.
Il runtime principale è la causa della non interoperabilità
con il
2015-03-25 12:32 GMT+01:00 Nicola Larosa n...@teknico.net:
Non risolve. Si mette un bel server davanti che gestisca i file statici,
e poi si scala orizzontalmente su tante macchine che fanno da application
server, con un bel cluster di database dietro.
E rispetto ad avere una macchina che
2015-03-25 12:45 GMT+01:00 Carlos Catucci carlos.catu...@gmail.com:
2015-03-25 12:32 GMT+01:00 Nicola Larosa n...@teknico.net:
Non risolve. Si mette un bel server davanti che gestisca i file statici,
e poi si scala orizzontalmente su tante macchine che fanno da application
server, con un
enrico franchi enrico.fran...@gmail.com wrote:
Bottom quoting is better than top quoting.
{
ma quanto mi disturbano le parentesi...
}
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Simone Federici wrote:
{
ma quanto mi disturbano le parentesi...
}
Eh, ormai ci ho rifatto il callo.
Pochi programmatori apprezzano il genio dell'indentazione significativa:
sarebbe stato un problema per l'adozione del linguaggio, ancor più dello
svantaggio di non poter avere funzioni
2015-03-25 9:00 GMT+00:00 Nicola Larosa n...@teknico.net:
Roberto De Ioris ha scritto:
Node e Go hanno deciso che basta un solo engine/approccio, il
primo ti dice che con la programmazione a callback fai tutto
(e vabbe' qui si apre un mondo [di bestemmie])
Esattamente. :-D
il
2015-03-25 11:36 GMT+01:00 Luca Bacchi bacch...@gmail.com:
Explicit is better than implicit.
Il giorno 25 marzo 2015 11:16, Carlos Catucci carlos.catu...@gmail.com
ha scritto:
Gollum, tutto tuo ;)
(Che gia' sara' incazzato per il tessorrro che si e' rotto)
Carlos
--
EZLN ... Para Todos
On 25 March 2015 at 11:58, Nicola Larosa n...@teknico.net wrote:
E in effetti gccgo, l'ultima volta che ho controllato, le mappava 1:1
sui thread dell'OS.
Sul serio?!? È sufficiente per impedirne l'uso in molti casi. :-(
Per i poveri mortali, che vuol dire?
Carlos
--
EZLN ... Para Todos
Enrico Franchi wrote:
E in effetti gccgo, l'ultima volta che ho controllato, le mappava
1:1 sui thread dell'OS.
Nicola Larosa wrote:
Sul serio?!? È sufficiente per impedirne l'uso in molti casi. :-(
Carlos Catucci wrote:
Per i poveri mortali, che vuol dire?
Impatta la scalabilità. Usare un
2015-03-25 9:28 GMT+00:00 Carlos Catucci carlos.catu...@gmail.com:
Si ma mi chiedo: serve davvero?
Io lo trovo molto comodo. Gli use-case che var non copre sono impagabili.
Poi chiaramente si puo' vivere senza, ma un sacco di cose sarebbero molto
piu' verbose.
--
.
..: -enrico-
2015-03-25 10:36 GMT+00:00 Luca Bacchi bacch...@gmail.com:
Explicit is better than implicit.
Bottom quoting is better than top quoting.
--
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
2015-03-25 8:40 GMT+00:00 Roberto De Ioris robe...@unbit.it:
Hmm si, fermo restando che la trovo una delle specifiche piu'
sovraingegnerizzate di python (che cavolo sembra una roba in java :P),
Sovraingegnerizzate? Si, e' vero, un po' e' cosi'. D'altra parte
l'alternativa sarebbe stata
enrico franchi wrote:
In realta' il comportamento che descrivi e' l'implementazione della
versione principale di go. Nella specifica, non dice niente su M -
N. Dice solo che viene chiamata as an independent concurrent thread
of control.
Grazie, m'era sfuggito.
E in effetti gccgo, l'ultima
Nicola Larosa wrote:
bisogna usare approcci più come gli eventi asincroni
...approcci più *leggeri* come..., uff.
--
Nicola 'tekNico' Larosa http://www.tekNico.net/
___
Python mailing list
Python@lists.python.it
2015-03-25 12:13 GMT+01:00 Nicola Larosa n...@teknico.net:
Avere un thread di sistema per ogni goroutine taglia le gambe.
E questo, se ho ben capito, con python si fa con molta fatica.
Speranze che il 3 possa risolvere questo problema?
Altra domanda, so che Django, ad esempio, e' usato in
https://www.paypal-engineering.com/2014/12/10/10-myths-of-enterprise-python/
--
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
52 matches
Mail list logo
