Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy

[alessandro medici]

>
> Quando parlo di memoria condivisa intendo a dettaglio implementativo,
> magari nascosto sotto l'astrazione di una libreria o di un linguaggio.
> Ad esempio in Rust alla fine *usi* memoria condivisa, ma il linguaggio
> ti permette di ragionare senza pensare a sincronizzazioni esplicite.
>

Concordo.

Occorrebbe che il linguaggio potesse chiamare dal sistema, ed ottenere,
un area condivisa da vari processi. Ed è proprio questo che mi piacerebbe.


> In Go puoi usare i channel, ma anche qui alla fine usi la memoria
> condivisa, solo che la sincronizzazione è gestita dal runtime.
> Ma sempre in Go, spesso la soluzione più semplice e suggerita in
> mailing list, è quella di usare un mutex.
>

Funziona davvero (in C) per riscrivere spesso, ma inutile se quel che ti
serve (in Python) è lavorare su
troppi dati eguali che cambiano ogni tanto :-(  e vanno riletti spesso.

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

[Python] sendkey e simili

[Filippo Dal Bosco -]

Vorrei sotto win 7 poter scrivere in automatico e ripetutamente su un
form di un programma 
Vorrei farlo in automatico su una window NON attiva, in altre parole
vorrei usare il PC per le mie necessità mentre lo script python
riempie il form.  

Ho fatto una breve ricerca ed altre a sendkey ho trovato questi:

pywinauto
PyAutoGui 
AXUI 
winGuiAuto 

Quale di questi riesce a lavorare su win 7  in "background", cioè su
una finestra NON attiva?

grazie


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

Re: [Python] EuroPython 2017 - Punto della situazione e Call for Volunteers

[Christian Barra]

Bene!

Per adesso conto:

Christian Barra
Patrick Arminio
Daniele Tricoli
Gaetano Scognamiglio
Marco Santoni
On 24 May 2016 16:35, "Daniele Tricoli"  wrote:

> On Monday, May 23, 2016 05:49:37 PM Christian Barra wrote:
> > La call for volunteers nell'oggetto e' riferita a questo.
>
> Contate su di me! Però dovrete spiegarmi meglio come essere utile!
>
> Ciao,
>
> P.S. Ho esperienza nel volontariato, ma non nell'organizzazione di un
> evento
> di tale portata. :D
>
> --
>  Daniele Tricoli 'eriol'
>  https://mornie.org
> ___
> 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] EuroPython 2017 - Punto della situazione e Call for Volunteers

[Daniele Tricoli]

On Monday, May 23, 2016 05:49:37 PM Christian Barra wrote:
> La call for volunteers nell'oggetto e' riferita a questo.

Contate su di me! Però dovrete spiegarmi meglio come essere utile!

Ciao,

P.S. Ho esperienza nel volontariato, ma non nell'organizzazione di un evento 
di tale portata. :D

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org

signature.asc
Description: This is a digitally signed message part.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy

[Manlio Perillo]

2016-05-24 15:00 GMT+02:00 enrico franchi :
>
> [...]
>> Perchè tutti i linguaggi (o meglio le loro implementazioni) attuali
>> che conosco, tranne Erlang (ed Haskell, come caso speciale), usano
>> memoria condivisa, anche se offrono supporto per il message passing
>> (tramite channel).
>
>
> Ma non e' questione di linguaggio: e' questione di applicazione. Il
> linguaggio diventa rilevante solo quando non ti lascia altra scelta.
>
>>
>> Quindi software normale scritto in questi linguaggi usa memoria condivisa.
>
>
> Mah... diciamo che non sono d'accordo. *Puoi* usare memoria condivisa.
> Certo. Questo non vuole dire che sia considerata una best practice farlo.
> Anzi.
>
> E mi sembra un trend dell'industria in un circolo virtuoso con quelli che
> fanno linguaggi e librerie. *Oggi* prova a presentare un design document
> fatto tutto a botte di synchronized e vediamo come va a finire (certo, se
> chi fa la review e' rimasto a come si faceva software negli anni '90 c'e'
> anche caso che passi...).
>

Quando parlo di memoria condivisa intendo a dettaglio implementativo,
magari nascosto sotto l'astrazione di una libreria o di un linguaggio.
Ad esempio in Rust alla fine *usi* memoria condivisa, ma il linguaggio
ti permette di ragionare senza pensare a sincronizzazioni esplicite.

In Go puoi usare i channel, ma anche qui alla fine usi la memoria
condivisa, solo che la sincronizzazione è gestita dal runtime.
Ma sempre in Go, spesso la soluzione più semplice e suggerita in
mailing list, è quella di usare un mutex.


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

Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy

[Marco Beri]

Il 24 mag 2016 3:02 PM, "enrico franchi"  ha
scritto:

> Ah, ok. Beh, allora vai in seg fault alla velocita' della luce,
sperabilmente prima di avere corrotto dati.

Se ci vai alla velocità della luce, per definizione ci arrivi prima. Non
serve sperare.

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

Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy

[enrico franchi]

2016-05-23 0:13 GMT+01:00 Manlio Perillo :

> > Nel 2016 praticamente tutti
> > quelli che hanno architettura a memoria condivisa le stanno migrando, a
> > parte in determinati casi specifici (e.g., embedded, kernel,
> possibilmente
> > roba come pipeline audio e video, dove hai veramente tanti dati e
> copiarli
> > diventa fastidioso).
> >
>
> A chi ti riferisci con "tutti"?
>


Il fatto che un linguaggio supporti la feature, non vuole dire che la devi
usare nella tua architettura.

Perfino in Java, che tradizionalmente era molto orientato nella direzione
della memoria condivisa, quasi tutti i nuovi pezzi di concorrenza sono
fatti per una strategia diversa.

Che so... pensa agli stream... Ma basta progettare in modo sensato cose
usando gli executor e ancora una volta *non* avrai stato non locale.




>
> Perchè tutti i linguaggi (o meglio le loro implementazioni) attuali
> che conosco, tranne Erlang (ed Haskell, come caso speciale), usano
> memoria condivisa, anche se offrono supporto per il message passing
> (tramite channel).
>

Ma non e' questione di linguaggio: e' questione di applicazione. Il
linguaggio diventa rilevante solo quando non ti lascia altra scelta.


> Quindi software normale scritto in questi linguaggi usa memoria condivisa.
>

Mah... diciamo che non sono d'accordo. *Puoi* usare memoria condivisa.
Certo. Questo non vuole dire che sia considerata una best practice farlo.
Anzi.

E mi sembra un trend dell'industria in un circolo virtuoso con quelli che
fanno linguaggi e librerie. *Oggi* prova a presentare un design document
fatto tutto a botte di synchronized e vediamo come va a finire (certo, se
chi fa la review e' rimasto a come si faceva software negli anni '90 c'e'
anche caso che passi...).




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

Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy

[enrico franchi]

2016-05-23 10:29 GMT+01:00 alessandro medici :

>
>> E capisci anche che praticamente *tutte* le operazioni su questi oggetti
>> devono essere protette da un lock. Perche'? Beh... perche' se siamo in
>> memoria condivisa vuole dire che piu' processi possono accedervi (o
>> meglio... se li ho messi in memoria condivisa e' perche' voglio accederci
>> da piu' processi).
>>
>> Ecco... come ne usciamo? Abbiamo due soluzioni:
>> 1. mettiamo un lock poco granulare sull'area di memoria
>> 2. mettiamo lock granulari sugli oggetti
>>
>
> Non mi sono spiegato: non si metterebbe NESSUN lock per l'accesso a
> quest'area. Sarebbero affari del programma quando come e perché lavorarci
> sopra.
>

Ah, ok. Beh, allora vai in seg fault alla velocita' della luce,
sperabilmente prima di avere corrotto dati.




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