Re: [Python] 10 myths

[Diego Barrera]

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.

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

Re: [Python] 10 myths

[Roberto De Ioris]

> 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 marea di engine di concorrenza, e alcuni di altissimo
livello e davvero per tutti i gusti.

Il problema forse e' proprio questo: ce ne sono troppi, e tutti
incompatibili tra di loro e 9 volte su 10 richiedono la riscrittura delle
librerie di comunicazione (come i db adapter e simili).

Chi dice che passare da sincrono ad asincrono sia una questione di monkey
patching, o e' molto fortunato o non ha capito una mazza di quello che sta
facendo.

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]), il secondo che i "thread in userspace"
(passatemi il termine) sono la cosa piu' bella del mondo.

Il non dover scegliere e' un grande vantaggio (ed e' anche una cosa molto
pythonica).


-- 
Roberto De Ioris
http://unbit.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Carlo Miron]

Il 25 marzo 2015 09:17, Roberto De Ioris  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 per tutti i gusti.
>
> Il problema forse e' proprio questo: ce ne sono troppi, e tutti
> incompatibili tra di loro e 9 volte su 10 richiedono la riscrittura delle
> librerie di comunicazione (come i db adapter e simili).
> [...]
> Il non dover scegliere e' un grande vantaggio (ed e' anche una cosa molto
> pythonica).

`asynchio` [¹]·[²]·[³] mira esattamente a risolvere questo problema.

[¹]: 
[²]: 
[³]: 

©

-- 
|:**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] 10 myths

[Roberto De Ioris]

> Il 25 marzo 2015 09:17, Roberto De Ioris  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 per tutti i gusti.
>>
>> Il problema forse e' proprio questo: ce ne sono troppi, e tutti
>> incompatibili tra di loro e 9 volte su 10 richiedono la riscrittura
>> delle
>> librerie di comunicazione (come i db adapter e simili).
>> [...]
>> Il non dover scegliere e' un grande vantaggio (ed e' anche una cosa
>> molto
>> pythonica).
>
> `asynchio` [¹]·[²]·[³] mira esattamente a risolvere questo problema.
>
>


Hmm si, fermo restando che la trovo una delle specifiche piu'
sovraingegnerizzate di python (che cavolo sembra una roba in java :P),
passeranno anni prima che si possa parlare di un qualcosa di concreto.

E poi vabbe', qualsiasi applicazione python scritta in asyncio non mi
sembra python :) Ho seguito un talk al fosdem (per carita' interessante),
ma mostrava in 20 righe quello che si fa da anni con 2... e il problema e'
che ne servono 2 anche in go e javascript/node :)


-- 
Roberto De Ioris
http://unbit.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Nicola Larosa]

>> 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 piu' bella del mondo.

Beh, il termine non rende molto l'idea. Le goroutine sono dei microthread
con un mapping M a N gestito dal runtime del linguaggio. Continuerei a
chiamarle goroutine per semplicità. :-)


>>> Il non dover scegliere e' un grande vantaggio (ed e' anche
>>> una cosa molto pythonica).

Vero, a volte Go mi sembra più pythonico di Python stesso. :-)


> Carlo Miron ha scritto:
>> asyncio mira esattamente a risolvere questo problema.

Giudizio personale, e scusate il pensiero sgradevole, ma too little, too
late. C'è un ecosistema pregresso che difficilmente cambierà. Python
continua a essere utile, ma il suo ruolo è ridimensionato. Il mondo va
avanti e la sua dominazione è ormai fuori portata, per così dire.


Roberto De Ioris ha scritto:
> Hmm si, fermo restando che la trovo una delle specifiche piu' 
> sovraingegnerizzate di python (che cavolo sembra una roba in java
> :P), passeranno anni prima che si possa parlare di un qualcosa di
> concreto.

Sgradevoli ricordi di Zope tornano alla mente...


> E poi vabbe', qualsiasi applicazione python scritta in asyncio non mi 
> sembra python :) Ho seguito un talk al fosdem (per carita'
> interessante), ma mostrava in 20 righe quello che si fa da anni con
> 2... e il problema e' che ne servono 2 anche in go e javascript/node
> :)

:-/

-- 
Nicola 'tekNico' Larosa 

Because of an unlikely combination of well-designed interface
types and the ability to upgrade to more efficient interfaces
when necessary, Go is able to serve files as efficiently as nginx
without your knowledge or cooperation. And that's fucking amazing.
 - Carl, 2014, http://avtok.com/2014/11/05/interface-upgrades.html
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Roberto De Ioris]

>>> 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 piu' bella del mondo.
>
> Beh, il termine non rende molto l'idea. Le goroutine sono dei microthread
> con un mapping M a N gestito dal runtime del linguaggio. Continuerei a
> chiamarle goroutine per semplicità. :-)
>
>


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..

Pace e poliamore...

-- 
Roberto De Ioris
http://unbit.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Nicola Larosa]

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


> Pace e poliamore...

Pace e poliamore sempre.


(Coppini in bagno e poliamore nello stesso messaggio mi lasciano
lievemente perplesso.)

-- 
Nicola 'tekNico' Larosa 

Because of an unlikely combination of well-designed interface
types and the ability to upgrade to more efficient interfaces
when necessary, Go is able to serve files as efficiently as nginx
without your knowledge or cooperation. And that's fucking amazing.
 - Carl, 2014, http://avtok.com/2014/11/05/interface-upgrades.html
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Roberto De Ioris]

> 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
>
>
>> Pace e poliamore...
>
> Pace e poliamore sempre.
>
>
> (Coppini in bagno e poliamore nello stesso messaggio mi lasciano
> lievemente perplesso.)

dannazione. punto tuo.


-- 
Roberto De Ioris
http://unbit.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Manlio Perillo]

On Mar 25, 2015 9:45 AM, "Carlo Miron"  wrote:
>
> Il 25 marzo 2015 09:17, Roberto De Ioris  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 per tutti i gusti.
> >
> > Il problema forse e' proprio questo: ce ne sono troppi, e tutti
> > incompatibili tra di loro e 9 volte su 10 richiedono la riscrittura
delle
> > librerie di comunicazione (come i db adapter e simili).
> > [...]
> > Il non dover scegliere e' un grande vantaggio (ed e' anche una cosa
molto
> > pythonica).
>
> `asynchio` [¹]·[²]·[³] mira esattamente a risolvere questo problema.
>

https://xkcd.com/927/

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

Re: [Python] 10 myths

[Carlos Catucci]

2015-03-25 10:10 GMT+01:00 Nicola Larosa :

> (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
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Carlos Catucci]

2015-03-25 9:17 GMT+01:00 Roberto De Ioris :

> 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 con il
costrutto := (che fa tanto pasQual). Ora, ho appena iniziato a cimentarmi,
per cui magari ci sono motivazioni ragionevolissime per cui si possono
dichiarare in due maniere diverse, pero' al momento io ancora non le ho
capite. Se qualche anima pia (ma pure se non troppo pia) mi desse qualche
dritta, magari finisce che Go possa piacermi. Anche perche' non capisco
perche' il povero = da solo non basti e debba avere appiccicato il : .

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

Re: [Python] 10 myths

[Nicola Larosa]

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 ;)

Perché sei ancora preda di una morale bigotta e repressiva. ;-)

-- 
Nicola 'tekNico' Larosa 

Because of an unlikely combination of well-designed interface
types and the ability to upgrade to more efficient interfaces
when necessary, Go is able to serve files as efficiently as nginx
without your knowledge or cooperation. And that's fucking amazing.
 - Carl, 2014, http://avtok.com/2014/11/05/interface-upgrades.html
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Carlos Catucci]

2015-03-25 10:11 GMT+01:00 Manlio Perillo :

> 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 ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Carlos Catucci]

2015-03-25 10:16 GMT+01:00 Nicola Larosa :

> 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 list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Nicola Larosa]

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


-- 
Nicola 'tekNico' Larosa 

Because of an unlikely combination of well-designed interface
types and the ability to upgrade to more efficient interfaces
when necessary, Go is able to serve files as efficiently as nginx
without your knowledge or cooperation. And that's fucking amazing.
 - Carl, 2014, http://avtok.com/2014/11/05/interface-upgrades.html
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Carlos Catucci]

On 25 March 2015 at 10:22, Nicola Larosa  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] posso usare il var per dichiarare una variabile senza
inizializzare e fare assegnamento dopo senza usare var oppure dichiarare e
inizializzare sempre con var. Perche' qui si deve usare un operatore
apposito? Un overloading non andava bene? Chiedo da ignorante (ma curioso)
perche' mi perplime. Voglio dire, crei un linguaggio da zero, lo crei
apposta per essere il piu' figo soto il rpfilo dell'eleganza ed efficienza,
deve esserci un perche' di certe scelte. Per dire il case in Python [cazzo
mi e' scappato] non serve e non e stato messo, nonostante ogni tanto
qualcuno sollevi di nuovo la questione. Dato che i tipi di Google sono
tutto tranne che idioti, avranno avuto una ottima ragione per farlo, ma mi
sfugge quale sia.

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

Re: [Python] 10 myths

[mauro]

> Il giorno 25/mar/2015, alle ore 10:10, Nicola Larosa  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' che 
l'ingombrante presenza di Go.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Enrico Bianchi]

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 del cazzo in un linguaggio 
con gc) e, soprattutto, per la distribuzione dell'applicazione finita 
(niente distutils, niente virtualenv, niente di niente, solo un 
eseguibile e vivi felice)...


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

Re: [Python] 10 myths

[Manlio Perillo]

2015-03-25 10:28 GMT+01:00 Carlos Catucci :

>
> On 25 March 2015 at 10:22, Nicola Larosa  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" serve in alcuni
punti, come ad esempio

for i := 1; i < 3; i++ {
fmt.Println(i)
}

Se leggi la specifica del linguaggio noterai che c'è anche un altra
importante differenza tra var e `:=`,
ad esempio:

func main() {
var x, err = foo()
y, err := foo()
 fmt.Println(x, y, err)
}

> [...]

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

Re: [Python] 10 myths

[Carlos Catucci]

2015-03-25 10:54 GMT+01:00 Manlio Perillo :

> 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 ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Luca Bacchi]

Explicit is better than implicit.

Il giorno 25 marzo 2015 11:16, Carlos Catucci  ha
scritto:

>
> 2015-03-25 10:54 GMT+01:00 Manlio Perillo :
>
>> 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 ... Para Todos Todo ... Nada para nosotros
>
> ___
> 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] 10 myths

[enrico franchi]

2015-03-25 10:36 GMT+00:00 Luca Bacchi :

> 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

Re: [Python] 10 myths

[enrico franchi]

2015-03-25 9:28 GMT+00:00 Carlos Catucci :

> 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-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Simone Federici]

enrico franchi  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

Re: [Python] 10 myths

[enrico franchi]

2015-03-25 8:40 GMT+00:00 Roberto De Ioris :

>
> 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 introdurre nuova sintassi, temo.

L'altra cosa che mi lascia dubbioso e' che e' una soluzione a problemi di
concorrenza, ma non di parallelismo. Viceversa le primitive di go risolvono
entrambi i problemi in modo uniforme.
Perfino Java, se fossero uscite prima le nuovissime API (con tipo 20 anni
di ritardo) invece che fare il classico macello con synchronized se la cava
meglio.



> E poi vabbe', qualsiasi applicazione python scritta in asyncio non mi
> sembra python :) Ho seguito un talk al fosdem (per carita' interessante),
> ma mostrava in 20 righe quello che si fa da anni con 2... e il problema e'
> che ne servono 2 anche in go e javascript/node :)
>

Beh, tutti quei framework hanno un po' sto problema. Anche un'applicazione
Twisted sembra piu' Twisted che Python. gevent mantiene la faccia di
Python, vero... ma il fatto che ti cambia sotto il cofano il comportamento
delle cose e' molto pericoloso. Il fatto che anche il semplice grequests
debba introdurre monkey patching globale (piuttosto che limitarsi ad essere
asincrono lui) mi da molto da pensare.

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

Re: [Python] 10 myths

[Nicola Larosa]

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 anonime inline.

Non credo che Pike e Thompson si siano proprio posti il problema se
mettercele o meno.

-- 
Nicola 'tekNico' Larosa 

Because of an unlikely combination of well-designed interface
types and the ability to upgrade to more efficient interfaces
when necessary, Go is able to serve files as efficiently as nginx
without your knowledge or cooperation. And that's fucking amazing.
 - Carl, 2014, http://avtok.com/2014/11/05/interface-upgrades.html

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

Re: [Python] 10 myths

[enrico franchi]

2015-03-25 9:00 GMT+00:00 Nicola Larosa :

> >> 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 piu' bella del mondo.
>
> Beh, il termine non rende molto l'idea. Le goroutine sono dei microthread
> con un mapping M a N gestito dal runtime del linguaggio. Continuerei a
> chiamarle goroutine per semplicità. :-)
>

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".
E in effetti gccgo, l'ultima volta che ho controllato, le mappava 1:1 sui
thread dell'OS.


> Giudizio personale, e scusate il pensiero sgradevole, ma too little, too
> late. C'è un ecosistema pregresso che difficilmente cambierà. Python
> continua a essere utile, ma il suo ruolo è ridimensionato. Il mondo va
> avanti e la sua dominazione è ormai fuori portata, per così dire.
>

Sono abbastanza d'accordo. Python su questo punto di vista e' rimasto al
palo.
E su tutto, non mi sono ancora chiare le implicazioni di efficienza a
runtime (e di memoria) di asyncio.


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

Re: [Python] 10 myths

[Carlos Catucci]

2015-03-25 11:36 GMT+01:00 Luca Bacchi :

> Explicit is better than implicit.
>
> Il giorno 25 marzo 2015 11:16, Carlos Catucci 
> ha scritto:
>

Gollum, tutto tuo ;)

(Che gia' sara' incazzato per il tessorrro che si e' rotto)

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

Re: [Python] 10 myths

[Nicola Larosa]

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 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 presto.

-- 
Nicola 'tekNico' Larosa 

Because of an unlikely combination of well-designed interface
types and the ability to upgrade to more efficient interfaces
when necessary, Go is able to serve files as efficiently as nginx
without your knowledge or cooperation. And that's fucking amazing.
 - Carl, 2014, http://avtok.com/2014/11/05/interface-upgrades.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Carlos Catucci]

On 25 March 2015 at 11:58, Nicola Larosa  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 Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Nicola Larosa]

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 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 gli eventi asincroni, o i "processi" di Erlang, o
appunto le goroutine del runtime di Go.

Avere un thread di sistema per ogni goroutine taglia le gambe.

-- 
Nicola 'tekNico' Larosa 

Because of an unlikely combination of well-designed interface
types and the ability to upgrade to more efficient interfaces
when necessary, Go is able to serve files as efficiently as nginx
without your knowledge or cooperation. And that's fucking amazing.
 - Carl, 2014, http://avtok.com/2014/11/05/interface-upgrades.html
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Nicola Larosa]

Nicola Larosa wrote:
> bisogna usare approcci più come gli eventi asincroni

"...approcci più *leggeri* come...", uff.

-- 
Nicola 'tekNico' Larosa 

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

Re: [Python] 10 myths

[Carlos Catucci]

2015-03-25 12:13 GMT+01:00 Nicola Larosa :

> 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 siti ad altissimo
carico. Come fa a risolvere con un numero threads molto elevato ?

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

Re: [Python] 10 myths

[Manlio Perillo]

On Wed, Mar 25, 2015 at 11:58 AM, Nicola Larosa  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 presto.
>
>
Se lo facesse, sarebbe un problema, IMHO.
Il runtime principale è la causa della non interoperabilità con il resto
del mondo, AFAIK.

> [..]

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

Re: [Python] 10 myths

[Nicola Larosa]

> 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 ad 
> altissimo carico. Come fa a risolvere con un numero di thread molto 
> elevato?

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.

Una volta sognavo di integrare Twisted e Django, poi mi son reso conto
della vanità del proposito. :-)

-- 
Nicola 'tekNico' Larosa 

Because of an unlikely combination of well-designed interface
types and the ability to upgrade to more efficient interfaces
when necessary, Go is able to serve files as efficiently as nginx
without your knowledge or cooperation. And that's fucking amazing.
 - Carl, 2014, http://avtok.com/2014/11/05/interface-upgrades.html
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Nicola Larosa]

> 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 usare librerie in C da Go tramite cgo. Non puoi al momento scrivere
facilmente librerie in Go da usare in C o in altri linguaggi.

Ian Lance Taylor ha progetti, non ancora operativi, per risolvere questo
problema:

Go execution modes


-- 
Nicola 'tekNico' Larosa 

Because of an unlikely combination of well-designed interface
types and the ability to upgrade to more efficient interfaces
when necessary, Go is able to serve files as efficiently as nginx
without your knowledge or cooperation. And that's fucking amazing.
 - Carl, 2014, http://avtok.com/2014/11/05/interface-upgrades.html
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Manlio Perillo]

On Wed, Mar 25, 2015 at 12:37 PM, Nicola Larosa  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 resto del mondo, AFAIK.
>
> La non-interoperabilità è unidirezionale.
>
> Puoi usare librerie in C da Go tramite cgo. Non puoi al momento scrivere
> facilmente librerie in Go da usare in C o in altri linguaggi.
>
>
Vero, ma chiamare funzioni C è inefficiente, per via dell'uso differente
dello stack (AFAIK).
Inoltre, sempre AFAIK, passare un puntatore ad una funzione C non ha un
comportamento ben definito, dato che il gc
può spostare le aree di memoria ed il runtime non supporta il pinning dei
puntatori.

Comunque, si, molti dei problemi sono puramente implementativi, ma forse
non tutti.

> [...]

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

Re: [Python] 10 myths

[Carlos Catucci]

2015-03-25 12:32 GMT+01:00 Nicola Larosa :

> 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 gestisce un numero elevatissimo di
thread e' una cosa meno buona se ho ben capito.

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

Re: [Python] 10 myths

[Manlio Perillo]

2015-03-25 12:45 GMT+01:00 Carlos Catucci :

>
> 2015-03-25 12:32 GMT+01:00 Nicola Larosa :
>
>> 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 gestisce un numero elevatissimo di
> thread e' una cosa meno buona se ho ben capito.
>
>
Costa di più, in termini monetari.
Se vuoi un framework "grasso" come Django, è il prezzo da pagare.

Se vuoi scalare, devi ripensare completamente all'*intera* architettura del
sistema.


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

Re: [Python] 10 myths

[Simone Federici]

Nicola Larosa :

> 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 gli eventi asincroni, o i "processi" di Erlang, o appunto le
> goroutine del runtime di Go.
>

Vista la vostra esperienza,
giusto per paragone, visto che conosco bene java,

Per scalare milioni di connessioni si usa un selector thread che gestisce
tutte le connessioni chiamate native I/O e attiva un thread da un pool per
gestire la richiesta una volta che che è arrivata. Questo permette di avere
migliaia di connessoni per JVM.

Tenendo conto che l'I/O è estremamente più lento di gestire una richiesta,
un solo selector thread gestisce facilmente tante socket ciclando su
ognuona di esse in modo sequenziale.

E i threads che gestisono le richieste sono rapidi in quanto non non sono
appesi ad aspettare bytes dalle socket.

c'è una libreria python che si avvicina a questo modello?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Roberto De Ioris]

> Nicola Larosa :
>
>> 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 gli eventi asincroni, o i "processi" di Erlang, o appunto le
>> goroutine del runtime di Go.
>>
>
> Vista la vostra esperienza,
> giusto per paragone, visto che conosco bene java,
>
> Per scalare milioni di connessioni si usa un selector thread che gestisce
> tutte le connessioni chiamate native I/O e attiva un thread da un pool per
> gestire la richiesta una volta che che è arrivata. Questo permette di
> avere
> migliaia di connessoni per JVM.
>
> Tenendo conto che l'I/O è estremamente più lento di gestire una richiesta,
> un solo selector thread gestisce facilmente tante socket ciclando su
> ognuona di esse in modo sequenziale.
>
> E i threads che gestisono le richieste sono rapidi in quanto non non sono
> appesi ad aspettare bytes dalle socket.
>
> c'è una libreria python che si avvicina a questo modello?
>


Sei sicuro che funzioni cosi' ? Proprio il mese scorso ho "smembrato" uno
stack j2ee (jboss, coucho resin ecc. ecc.) e da quello che ho visto il
thread selector si limita a chiamare l'accept() e tenere il file
descriptor "in coda" nell'attesa che ci sia un thread in attesa (tra
quelli fissi del pool).

Quindi hai solo aumentato la mole di richieste che puoi mettere in coda,
non quante ne puoi gestire in concorrenza. (il che mi sembra un
bell'approccio enterprise per vendere a qualche dirigente bambacione)


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 :)



-- 
Roberto De Ioris
http://unbit.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Roberto De Ioris]

> 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 volta che ho controllato, le mappava 1:1
>> sui thread dell'OS.
>
> Sul serio?!? È sufficiente per impedirne l'uso in molti casi. :-(

Solo nella primissima incarnazione.

Gia' nel 4.8 si usava makecontext()/swapcontext(), con l'aggravante che
ogni volta che veniva fatta una chiamata a una libreria C veniva generato
un pthread (ma questo succedeva anche con le prime versioni di go, proprio
per evitare casini con lo stack).

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.

Inoltre il runtime di gccgo si embedda (anche se in modo rocambolesco,
vedere mio post di qualche giorno fa) in ambienti c/c++/obj-c quindi e' un
bel vantaggio. E purtroppo (mi tocca dirlo) l'unico di gccgo :(



-- 
Roberto De Ioris
http://unbit.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Simone Federici]

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 un solo context switch sull'accept.

però hai diversi eventi da sottoscrivere.

SelectionKey.OP_CONNECT
SelectionKey.OP_ACCEPT
SelectionKey.OP_READ
SelectionKey.OP_WRITE

channel.configureBlocking(false);

SelectionKey key = channel.register(selector, SelectionKey.OP_READ |
SelectionKey.OP_WRITE);

ad esempio netty ha una implementazione parrecchio interessante.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Daniele Tricoli]

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 piacevolmente colpito è che gofmt, in più di un 
progetto, è richiesto per contribuire. Quindi il problema di educare 
all'indentazione significativa è in parte mitigato: alla fine oltre a 
richiedere i test basta anche richiedere l'uso di gofmt.

> Non credo che Pike e Thompson si siano proprio posti il problema se
> mettercele o meno.

Magari non se lo sono posti, ma quello che sta emergendo alla fine non è un 
brutto compromesso.

-- 
 Daniele Tricoli 'Eriol'
 http://mornie.org
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[Marco Santamaria]

Il giorno 25 marzo 2015 11:50, Nicola Larosa  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 l'adozione del linguaggio, ancor più dello
> svantaggio di non poter avere funzioni anonime inline.
>
> Non credo che Pike e Thompson si siano proprio posti il problema se
> mettercele o meno.
>

Pare che se lo siano posto il problema. In questo articolo
 viene motivata la scelta di
evitare l'indentazione per delimitare i blocchi di codice:


Some observers objected to Go's C-like block structure with braces,
> preferring the use of spaces for indentation, in the style of Python or
> Haskell. However, we have had extensive experience tracking down build and
> test failures caused by cross-language builds where a Python snippet
> embedded in another language, for instance through a SWIG invocation, is
> subtly and *invisibly* broken by a change in the indentation of the
> surrounding code. Our position is therefore that, although spaces for
> indentation is nice for small programs, it doesn't scale well, and the
> bigger and more heterogeneous the code base, the more trouble it can cause.
> It is better to forgo convenience for safety and dependability, so Go has
> brace-bounded blocks.



Ma non riesco a digerire questo fatto...
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] 10 myths

[enrico franchi]

On Wed, Mar 25, 2015 at 10:58 AM, Nicola Larosa  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 ho letto da
diverse fonti.
Se non fosse piu' cosi', non lo e' da poco.



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

Re: [Python] 10 myths

[enrico franchi]

2015-03-25 11:13 GMT+00:00 Nicola Larosa :

> 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 di fare cosi'.
In pratica tutto il codice Java "moderno" fa uso di thread pool.

Aggiungo, con i completable futures e gli streams hanno effettivamente
"nascosto" almeno come default la gestione manuale del thread pool e fa la
cosa giusta.



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

Re: [Python] 10 myths

[enrico franchi]

2015-03-25 11:17 GMT+00:00 Carlos Catucci :

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 che il tuo servizio dovra' scalare, e
semplicemente non fai cose blatantemente cretine (tipo basarti su thread
1:1).

I problemi che io trovo sono quando hai sistemi misti, con parti I/O bound
notevoli ma anche componenti CPU bound. E l'unica cosa che puoi fare e'
spezzare a livello architetturale il servizio. E tipicamente devi farlo fin
da subito. E tipicamente questo vuole dire aumentare ancora il costo
dell'I/O oppure fare magheggi con processi e memoria condivisa, gia' che ci
sei zero-copy (che e' roba abbastanza facile da cazzare)

Speranze che il 3 possa risolvere questo problema?
>

Avrebbe dovuto essere AsyncIO


> Altra domanda, so che Django, ad esempio, e' usato in siti ad altissimo
> carico. Come fa a risolvere con un numero threads molto elevato ?
>

A livello architetturale.



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

Re: [Python] 10 myths

[enrico franchi]

2015-03-25 11:55 GMT+00:00 Manlio Perillo :

> Costa di più, in termini monetari.
>

Non solo: e' anche molto piu' complesso calcolare l'availability.


>
>


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

Re: [Python] 10 myths

[enrico franchi]

2015-03-25 12:14 GMT+00:00 Simone Federici :

c'è una libreria python che si avvicina a questo modello?
>

Con Twisted e' essenzialmente "gratis", ed e' piuttosto facile da
implementare con gevent.

Dopo di che, entrambi si comportano malissimo quando hai pezzi che sono CPU
bound, mentre Java se ne fa relativamente un baffo.


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

Re: [Python] 10 myths

[enrico franchi]

2015-03-25 12:36 GMT+00:00 Roberto De Ioris :

> 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?


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

Re: [Python] 10 myths

[Roberto De Ioris]

> 2015-03-25 12:36 GMT+00:00 Roberto De Ioris :
>
>> 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?
>
>

direi di si (a meno che non sia cambiato qualcosa di recente)

-- 
Roberto De Ioris
http://unbit.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python