[Python] tk talvolta è comodo

[alessandro medici]

https://github.com/LionKimbro/lions_internet_office/blob/main/2021/users/lion/entries/2021-09-18_tkinter-direct.md
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python

Re: [Python] aiuto creazione bot login e apertura pagine

[alessandro medici]

Il Lun 10 Ago 2020, 13:34 Carlos Catucci  ha
scritto:

>
>
> On Mon, 10 Aug 2020 at 10:50, Angelo Ballacchino <
> angelo.ballacch...@edu.unito.it> wrote:
>
>> ciao a tutti , vorrei chiedere delle informazioni per fare un bot ,per
>> fare login su un sito e aprire pagine attraverso automaticamente chiedo
>> informazioni riguardo degli spunti di source code.
>>
>
> Puoi usare selenium per farlo. Non so se vada bene anche Mechanize.
>
> Carlos
> --
> Si. Ma se Tri javascript  sei nei guai. Non ho cercato a fondo, ma non ho
> trovato nulla di utile.
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python

Re: [Python] (senza oggetto)

[alessandro medici]

Il giorno mer 22 apr 2020 alle ore 00:20 Marco Beri 
ha scritto:

> On Wed, Apr 22, 2020 at 12:12 AM Lamb Don  wrote:
>
>> ciao
>> Mi sono iscritto da poco attendo vostre news.
>>
> Don
>>
>
> Guarda, qui è un casino! Non si esce di casa da un mese e passa.
>
> Però ogni tanto vado a fare la spesa.
>
> Per fortuna sono calvo, quindi non sento la mancanza del parrucchiere.
>

ok, rompo il mio lurking che osservo strettamente da qualche anno.



> That's it.
>
> Ciao.
> Marco.
>

Grande. Un attimo di vivacità aiuta sempre.



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

Re: [Python] Iterare in una lista.

[alessandro medici]

Di passaggio: se non l'hai capita era perché evidentemente sono stato poco
chiaro nei commenti.
In effetti quella classe fa parecchie cose anche complicate.

Per lumi sono sempre disponibile, meglio se in privato così non si da
fastidio a nessuno.

E, magari, se mi fai delle domande, posso migliorarne la documentazione.

Bye!

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

Re: [Python] Iterare in una lista.

[alessandro medici]

Il dom 16 feb 2020, 19:27 Daniele Zambelli  ha
scritto:

> Il giorno sab 15 feb 2020 alle ore 20:04 alessandro medici
>  ha scritto:
> >
> >
> > Oggi è sabato. La cosa mi ha divertito ed ho pensato che valesse la pena
> generalizzare il problema:
> >
> >
> https://github.com/AlessandroMedici/add_a_mood_for_slice/blob/master/RepSlip.py
>
> Interessante... ma non l'ho capita
>



> :)


> Il giorno gio 13 feb 2020 alle ore 16:23 Gabriele Battaglia <
iz4...@libero.it> ha scritto:
> Buona sera.
> Se ho una lista che contiene 10 elementi e voglio scrivere un ciclo che
> itera dall'elemento 5, arriva alla fine e riprende finendo al 4.
> A parte gestire autonomamente l'indice con un algoritmo, esiste una
> funzione già presente in Python per farlo?
> Gabry

No, in effetti. La cosa però mi aveva incuriosito abbastanza perché l'idea
mi potrebbe esser utile,
se più generalizzata. Non solo alle liste, quindi.
L'uso è piuttosto semplice, supponendo tu abbia una lista:

lista = [0,1,2,3,4,5,6,7,8,9]
lista = Repslicing(lista)

a questo punto puoi iterare la nuova lista anche con gli indici necessari a
te:

lista = lista[5:5]
in lista troverai:
lista
[5,6,7,8,9,0,1,2,3,4]

p.s. stamane ho sistemato anche un paio di bug e spero anche di aver
corretto l'inglese da sabato sera :)))
p.p.s. la parte relativa agli indici negativi ed a step puo' essere
bellamente ignorata.

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

Re: [Python] Iterare in una lista.

[alessandro medici]

Oggi è sabato. La cosa mi ha divertito ed ho pensato che valesse la pena
generalizzare il problema:

https://github.com/AlessandroMedici/add_a_mood_for_slice/blob/master/RepSlip.py
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python

Re: [Python] Scelta GUI

[alessandro medici]

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

Re: [Python] zero alla zero

[alessandro medici]

Più che una convenzione di python è una regola della matematica: qualsiasi
numero elevato alla zero ha come valore 1.

My cent... :-)

Il 06/ago/2016 10:40, "Daniele Zambelli"  ha
scritto:

> Mi è crollato un mito!
>
> >>> pow(0, 0)
> 1
> >>> 0**0
> 1
>
> Perché Python fa queste cose?
>
> ...
>
> Poi cercando un po' in Internet ho visto che nell'informatica questa
> "convenzione" è molto diffusa. Mah...
>
> Buona estate.
>
> --
>
> Daniele
>
> www.fugamatematica.blogspot.com
>
> giusto!
> nel verso
> forse è perché non guardiamo le cose
> Quando non ci capiamo,
> ___
> 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] pensierino della sera sul multiprocessing, sul cambiare le carte in tavola, sui seg-fault e sulla memoria già condivisa,

[alessandro medici]

>
>
> Ti consiglio di leggere un buon libro su come ci si interfaccia con il
> kernel di un sistema UNIX.
> Ad esempio
> The Linux Programming Interface: A Linux and UNIX System Programming
> Handbook
> o il classico
> Advanced Programming in the UNIX Environment
>

Grazie dei suggerimenti :-)

Ma stai anche dicendo che le stesse procedure valgono per windows?

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

Re: [Python] Insiemi e multiprocessor.

[alessandro medici]

>
>
> > In effetti, cercando un termine più adeguato, forse 'categorie'
> > sarebbe più corretto.
> > E 'categorizzare' (odio queste parole in zzare), il lavoro che
> > potrebbe fare un metodo
> > della classe scritto in pyDialog.
> >
>
> Non conosco pyDialog e non ho capito bene cosa cerchi... ma magari
> questo può interessarti:
> http://docs.sympy.org/dev/modules/sets.html
>
> Pietro
>
> Grazie. E' borderline rispetto a cosa cercavo, ma per certe cose sarà
sicuramente
assai utile.

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

[Python] Practical lock-free concurrency (in C++)

[alessandro medici]

La seconda parte vedrò di non perdermela:

http://www.oreilly.com/pub/e/3735?imm_mid=0e442b=em-prog-na-na-newsltr_20160528

La prima parte è qui:

http://www.oreilly.com/pub/e/3706

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

Re: [Python] Insiemi e multiprocessor.

[alessandro medici]

In effetti, cercando un termine più adeguato, forse 'categorie' sarebbe più
corretto.
E 'categorizzare' (odio queste parole in zzare), il lavoro che potrebbe
fare un metodo
della classe scritto in pyDialog.

Qualcosa di più di un set. Qualcosa in meno di un insieme.
​

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

[Python] pensierino della sera sul multiprocessing, sul cambiare le carte in tavola, sui seg-fault e sulla memoria già condivisa,

[alessandro medici]

Stasera, giusto per prender sonno, stavo leggendo Python Parallel
Programm etc. etc. Comprato in una svendita online col 75% di sconto :-)

[NON E' PUBBLICITA': Scritto bene nella parte teorica e nello spiegare, a
parte qualche sassolino. Almeno per quel che ne posso dire io. Molto meno
bene (quasi pessimo?) nel codice stampato, poco meglio lo scaricabile. Poco
importa però e forse: sciocchezze e questioni di stile, e mi sembra anche
che da qualche parte scriva che il suo testo non sia proprio da neofiti]

Ma sorry: vedo anche due cose:

1° è l'uso estensivo dei dizionari creati nel processo padre ed aggiornati
dai processo figlio, sia nelle voci che nel contenuto. Un giro rapido e,
stupore, non solo i dizionari, ma anche liste. L'unica cosa che non ho
visto fare è applicare il metodo __del__, cosa comprensibile, peraltro,
almeno per la salute mentale del memory manager.
Ecco: basterebbe FORSE creare un'altro dizionario delle voci che andrebbero
cancellate e poi, magari, farlo dopo?
Ok, 1° compito prima delle vacanze: Ma i dizionari sono pressoché gli unici
oggetti composti che si possono aggiornare in multiprocess?

La 2° viene dall'altra idea:
Mi era venuto subito in mente quando lessi l'articolo che postai qualche
giorno addietro, quel qualcosa sul cambiare le ruote alla bici mentre si
pedala:
http://mathamy.com/python-wats-mutable-default-arguments.html
cosa succederebbe se cambiassi le variabili di default di una classe o di
un metodo mentre la loro progenie è occupata in un processo? Magari in una
ABC genitore?

Forse nulla. Forse dipenderà dal metodo con cui si lanceranno i processi? (
https://docs.python.org/3.5/library/multiprocessing.html#the-spawn-and-forkserver-start-methods
usa inherits ma non chiarisce se intende 'copiare' o 'linkare')

Forse salto in aria :)

E poi vedo Enrico leggermi, e che già chiede per me a viva voce un TSO,
pensare ancora più a ragione un 'ma chi me lo fa fare'? Eddai: forza e
coraggio Enrico, ormai sono sulla via della tomba, che quella con la r in
più ormai la vedo raramente :-(

E però sono curioso. E per due mani di pittura dovrebbero bastare poche
ore, come disse il pittore prima di scoprire che si trattava della torre
Eiffel.

Alex

ps: la vera perla però è che ho trovato anche che non mi occorrerà sprecare
tempo e denaro nel mare di sangue per avere un'area dati shared tra
processi, esiste già, si veda:
17.2.1.5. Sharing state between processes¶

nella pagina che cito poco sopra e poi si dia un ctrl-f su shared memory.

Evidentemente il timore del seg-fault non li ha fermati. Ed, a me, averla
organizzata come array mi va benissimo: il mappare dati in modo diverso nel
Cobol era una delle cose più divertenti da fare nell'epoca di quando ero un
ragazzino. Almeno quando ero vestito.
(Al riguardo dei vestiti il BDFL ed io il  abbiamo le stesse idee. E anche
la stessa età :-(  :)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Insiemi e multiprocessor.

[alessandro medici]

Il giorno 27 maggio 2016 17:15, Andrea D'Amore  ha
scritto:

> On 27 May 2016 at 13:38, enrico franchi  wrote:
> >> s3 = set([i for i in s if una_terza_proprietà(i)])
>
> > Le quadre sono non desiderabili in questo.
>
> Intedi meglio le generator expression per evitare di istanziare tutti
> gli elementi?
>

Credo intendesse pleonastiche.

ps: si vede che mi sto annoiando a morte...
Venerdì del piffero... :(
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[alessandro medici]

Il giorno 27 maggio 2016 15:51, alessandro medici <
alexxandro.med...@gmail.com> ha scritto:

>
> Il giorno 27 maggio 2016 14:54, Roberto Polli <robipo...@gmail.com> ha
> scritto:
>
>> Il 27 maggio 2016 14:41, enrico franchi <enrico.fran...@gmail.com> ha
>> scritto:
>> > Scusa, e come fai a sapere che gli altri processi *non* ci lavorano?
>>
>> Con un broker ;)
>>
>> https://en.wikipedia.org/wiki/Software_transactional_memory
>>
>> @alessandro.medici se vuoi sperimentare, l'affare STM pare croccante,
>> io ovviamente so solo che esiste ;)
>
>
ecco, senza cercarlo:

http://pypy.readthedocs.io/en/latest/stm.html

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

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

[alessandro medici]

Il giorno 27 maggio 2016 14:54, Roberto Polli  ha
scritto:

> Il 27 maggio 2016 14:41, enrico franchi  ha
> scritto:
> > Scusa, e come fai a sapere che gli altri processi *non* ci lavorano?
>
> Con un broker ;)
>
> https://en.wikipedia.org/wiki/Software_transactional_memory
>
> @alessandro.medici se vuoi sperimentare, l'affare STM pare croccante,
> io ovviamente so solo che esiste ;)
>

La pagina che ho appena passato nella mail precedente lo richiama, alla fine
di una serie di ottime ed interessanti osservazioni. Sul fatto che sia
croccante
non dubito.
Sul fatto che le mie ferie siano limitate, meno ancora :-(

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

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

[alessandro medici]

Il giorno 27 maggio 2016 14:41, enrico franchi <enrico.fran...@gmail.com>
ha scritto:

>
>
> 2016-05-25 18:02 GMT+01:00 alessandro medici <alexxandro.med...@gmail.com>
> :
>
>>
>>>
> Perche' scusa... se sai fare una libreria che ti consente di avere oggetti
> condivisi fra processi *senza* bisogno di lock, allora direi che sai anche
> fare una libreria che ti consente di condividere oggetti fra thread *senza*
> bisogno di lock.
> E a questo punto hai finito, hai vinto. Hai ucciso il GIL.
>

Magari. Sto solo cercando un modo che mi permetta di lavorare più
comodamente.
Se e come e quanto sarà possibile, vedrò.
E giuro sulla mia tessera di Giovane Marmotta che, quando tornerò dai bagni
rossi
relazionerò sul mio più che probabilmente certo fallimento :-)

ps:
http://python-notes.curiousefficiency.org/en/latest/python3/multicore_python.html
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Insiemi e multiprocessor.

[alessandro medici]

Il giorno 27 maggio 2016 14:20, enrico franchi 
ha scritto:

>
>
> Non ti seguo nel discorso logico e matematico: la mia formazione non
comprende
proprio l'insiemistica: tout court, quel poco che so non è di certo
avanzato o altro.
Io mi sono formato soloai sistemi di equazioni alle differenze finite.
Quindi prendo per buono quello che dici e mi fido.
Eh, no. Di certo non sono un matematico: mi piace e mi diverto se qualcuno
mi spiega
qualcosa di nuovo, ma non ho voglia di rimettermi davvero a studiare. Al
limite chiamo
qualche amico quando ne ho davvero bisogno.

Ah, prolog. Non era casuale se ieri citavo pyDialog. Sostanzialmente
implementa
in python una logica prolog e parte della sua sintassi.


> E qui si scopre che uno dei primi concetti da gestire e' quello di modello
> stabile e poi di modello ben fondato (incidentalmente, la mia tesi
> magistrale era su sta roba). E si scopre anche che non ci sono modi
> efficienti per implementare la semantica di modello ben fondato in un
> linguaggio di programmazione. Wikipedia sostiene che ci siano algoritmi
> quadratici per calcolarlo (ma a suo tempo mi pare fosse ben piu'
> complicato, io ricordo che eravamo molto contenti di averlo fatto in modo
> cubico). E quindi si arriva ad answer set programming.
>
>
> Ma insomma... TL;DR
>
> MediciSet("is zero of Zeta Function") & MediciSet("is complex and has real
> part == 1/2")
>
> Se hai veramente implementato gli insiemi "come li vuoi tu", mi sai anche
> calcolare quella roba lassu'. Se sai calcolare quella roba lassu', hai
> appena dimostrato (o disprovato) l'ipotesi di Riemann e diventi il
> matematico piu' importante della nostra generazione. Si... ho saltato un
> botto di passaggi per arrivare dal pappardello a questa versione breve.
>

:-) magari, ma non credo proprio.

>
>
Ora... buona fortuna. Ma per un uso pratico degli insiemi, non ti serve
> niente di cui sopra... e li hai gia'. Per esempio... vuoi sapere se un ente
> matcha certe proprieta'? Banale. Ci sono anche librerie -- tipo hamcrest --
> che ti rendono facile scrivere le regole. Se le regole sono relativamente
> semplici computazionalmente e parti da un insieme finito, puoi anche
> calcolarlo facilmente. Se l'insieme e' infinito, beh... amen. Puoi comunque
> comporre regole e compagnia e testare ogni candidato.
>

hamcrest? Ok, in cartella anch'esso. Peccato che non ho mesi di ferie :-)

>
> Quindi non capisco cosa siano i tuoi insiemi. Non possono essere "i veri
> insiemi" (scusa, ma sono scettico sul fatto che in un estate rifondi tutta
> la logica computazionale risolvendo alcuni dei problemi piu' ardui della
> materia). E quindi che resta... quello che gia' abbiamo. O mi sono perso
> qualcosa?
>

Verissimo: non sono veri insiemi sal punto di vista matematico. Purtroppo
non ricordo
neppure esattamente il cosa, come e perché mi servivano.
Ricordo solo, e vagamente, che stavo scrivendo qualcosa relativo
alla previsione degli andamenti futuri di alcuni fatti aziendali. Ricordo
ancora
che utilizzavo sostanzialmente un metodo basato su medie mobili inventato
da un tizio
che, allora, lavorava per la Fiat, e che si chiamava Lewandoskj. E che
cercavo di accoppiare
diverse situazioni per vedere quanto, come e dove, si potevano trovare
indicatori storici
di previsione chiamiamoli A, B, ... per una ragionevole previsione di un
altro valore futuro Teta.

A quei tempi bastava e, stranamente, funzionava anche decentemente. Oggi,
con
il mondo che cambia così alla svelta, avrei dei dubbi molto grossi sulla
fattibilità
di previsioni di quel tipo non dico a 12 mesi, ma anche a 3/6.

Il che non toglie nulla al fatto che la voglia mi è rimasta e quindi
indagherò sul
tema. E credo non sia casuale, di nuovo, che cercando mi sia imbattuto in
pyDialog.

Il fatt'è, tutto sommato, che programmare ed imparare cose nuove mi diverte
oggi come allora.

Alex

ps: anche se non c'entra una mazza: a voi risulta che Anaconda implementi
il threading
in modo molto più efficiente (intendo veloce) di Cpython su Linux?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Insiemi e multiprocessor.

[alessandro medici]

Il giorno 26 maggio 2016 17:21, Pietro Battiston  ha
scritto:

>
>
> Tutta l'idea di fondo (per quel che ne so io, e per questo chiedevo) di
> scikit-learn è identificare a quale categoria appartengono gli oggetti
> _senza poterlo chiedere direttamente ad ogni oggetto_, ma costruendo su
> un sample di training modelli capaci di fare poi predizioni out of
> sample.
>
> Comunque Alessandro diceva chiaramente che i set python non lo
> soddisfano. Quindi non stava certo parlando di un semplice
>
> s = set(un_poco_di_roba)
> s1 = set([i for i in s if una_qualche_proprietà(i)])
> s2 = set([i for i in s if una_seconda_proprietà(i)])
> s3 = set([i for i
> in s if una_terza_proprietà(i)])
>
> ... che pure si potrebbe definire "Identifying to which category an
> object belongs to."
>

In effetti pensavo a qualcosa di assai più complesso ma, ovvio,
trovare tutta la torta precotta è assai raro, anche se ormai con tutta
sta gente che si interessa a python (http://pypl.github.io/PYPL.html)
di cose se ne trovano ormai a bizzeffe.

Comunque per identificare a quale categoria dipende dal tipo di modello
che utilizzi per 'belong to': la chiave puoi impostarla come:

kernel = fn_appropriata_in_python_che_estrae_quello_che_voglio_dai_dati da
scandagliare

che dovrò pensare in qualche modo. E provare.

Al riguardo anche pyDatalog ha un sacco di cose carine per
automatizzare operazioni di questo tipo. Ed è anche
thread-safe.

Bene, ho aggiunto anche questo ai compiti delle vacanze nel mare di sangue.
Ammesso che allora ne abbia il tempo :-(

Alex

ps: che ormai ha solo qualche ora per finire i compiti per oggi :-(
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Insiemi e multiprocessor.

[alessandro medici]

>
>
> > Sono un imbecille a cercare di reinventare la ruota:
> >
> > http://scikit-learn.org/stable/
> >
>
> Confesso che non colgo il nesso...
>
> Pietro
>
> Tra le tante cose che può fare è in grado di fare esattamente quel che
cercavo.
E non è neppure il solo. Sorry del rumore in lista.

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

Re: [Python] Insiemi e multiprocessor.

[alessandro medici]

Sono un imbecille a cercare di reinventare la ruota:

http://scikit-learn.org/stable/
​
Alex
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Insiemi e multiprocessor.

[alessandro medici]

Il giorno 26 maggio 2016 10:17, giulianc51 <giulian...@gmail.com> ha
scritto:

> Il giorno Wed, 25 May 2016 23:57:48 +0200
> alessandro medici <alexxandro.med...@gmail.com> ha scritto:
>
> ciao Alessandro,
>
>
> > Rioops:
> >
> > d) se non gli passo le caratteristiche dell'insieme è in grado di
> > creare gli insiemi che accomunano il gruppo di oggetti che gli passo.
> > Probabilmente ne sarebbe la funzione più utile.
>
> credo che i due modi in letteratura di definire gli insiemi siamo
> quello *enumerativo*, ad es. A = {a,b,c,d,e}, D = {1,3,5,7}, valido
> per insiemi finiti, e quello *per caratteristiche* (non ricordo, scusa,
> il termine esatto), ad es. A = {n in N | mod(n,2) = 0} = {2,4,6,.},
> valido per insiemi anche infiniti;
>

Esattamente il secondo modo.

>
> per quanto quì parliamo per definizione di insiemi finiti, azzardo
> l'opinione che il secondo metodo rappresenti una soluzione più
> interessante; in ogni caso temo dovrai partire da quì;
>
> Perché temere: si tratta solo (?) di trovare dei criteri per individuare
caratteristiche comuni in un gruppo di dati. Ovvio che poi è solo
questione di potenza di calcolo in relazione alla numerosità ed alla
complessità dei dati.


> credo avrai anche un'altra difficoltà a seconda che i tuoi insiemi
> siano una partizione (e quindi ad intersezione nulla) oppure ad
> intersezione nonnulla, potendo in tal caso un oggetto appartenere a più
> insiemi;
>

Già, ma non è una difficoltà reale. Anche qui è solo questione di calcolo.


> (richiedo scusa se non ho capito una cippa del tuo discorso, sii
> generoso e passa oltre :-)
>
> ciao,
> giuliano
>
>
Hai capito perfettamente. Ma domandavo qui solo per sapere se qualcuno
ha già affrontato l'argomento. Credo di si perché è un approccio
abbastanza logico se si deve affrontare una serie di dati non ordinati
e diversamente strutturati.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Wireless barcode scanner

[alessandro medici]

https://www.packtpub.com/hardware-and-creative/internet-things-python?utm_source=all+updates_campaign=71eb39f09e-Deal_of_the_Day_May_25th_2016_medium=email_term=0_c970747b22-71eb39f09e-168741153_cid=71eb39f09e_eid=288071b148

E ci colleghi una telecamera...
ma, al solito, ti devi scrivere tutto il codice da te. E poi usa il 2.7.

Bleah!!

Alex

ps: ire furibonde?
​
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Insiemi e multiprocessor.

[alessandro medici]

Rioops:

d) se non gli passo le caratteristiche dell'insieme è in grado di creare
gli insiemi che accomunano il gruppo di oggetti che gli passo.
Probabilmente ne sarebbe la funzione più utile.

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

Re: [Python] Insiemi e multiprocessor.

[alessandro medici]

oops, me ne sono dimenticato:

tia.
​

ps: la buona educazione di questi tempi va spesso a farsi fottere. Beata
lei che, almeno, si diverte.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Insiemi e multiprocessor.

[alessandro medici]

Toh, che bello. Non sono ancora del tutto preda dell'Alzheimer: mi sono
ricordato.

La cosa nasce poco meno di una quarantina di anni fa.

All'epoca tiravo moccoli in basic, cobol ed, ancora più spesso, con
l'assembly del 6010
e dello z80... Poi è arrivato lo z8000 e mi è sembrato di rinascere :-)

Una delle cose di cui sentivo disperatamente la mancanza erano gli oggetti.
Vi assicuro
che creare pseudo-oggetti in basic era alquanto devastante, anche se utile.
Ed all'epoca
il testing era tutto da implementare a manina.
Per fortuna poi qualcuno ha rimediato ed, almeno da questa parte, il mio
animo si è
rappacificato con il mondo.


Ma la seconda mi è rimasta come un fastidio che talvolta viene a galla:

Vorrei trovare (oppure scrivere, tanto ormai, aspettare ancora non ha molto
senso) una libreria
(od una classe o quello che sarà) che implementasse la pura logica degli
insiemi (non i set di python).

Potrebbe essere una classe del tipo:

a) definisce le caratteristiche di un insieme. E' in grado di leggere e
confrontare la compatibilità
di queste caratteristiche con quelle di un oggetto che gli viene passato.
Ne prende nota. Ovvio che con un ciclo di combinazioni recursive posso
anche definire quali e quanti sotto-insiemi potrebbero essere creati. Come
a dire che ogni qualvolta ho un dato qualsiasi posso testarlo per sapere se
è ok per quell'insieme (una cosa del tipo: if it looks like a a duck and
quacks like a duck, it must be a duck.

b) mi torna il set degli oggetti che sono 'duck' ed il set di quelli
not-duck.

c) posso avere il set dei subset (al livello/numero di combinazioni che
voglio) che sono, tra loro, 'duck'.

Poi basterebbe usare set. Per il resto.

Ovvio che è un lavoro decisamente cpu bond. Ed anche che, se non voglio
aspettare la notte dei tempi per un programma in 'real time', bisogna usare
multiprocessor.

A che servirebbe? Big Data? Semplificare da matti il codice? All'epoca
avrei dato la mano destra per averla (ok, sono mancino, ma esiste un limite
a tutto).

Alex

ps: qualcuno conosce qualcosa al riguardo?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[alessandro medici]

Il giorno 25 maggio 2016 18:25, enrico franchi <enrico.fran...@gmail.com>
ha scritto:

>
>
> 2016-05-25 17:07 GMT+01:00 alessandro medici <alexxandro.med...@gmail.com>
> :
>
>>
>>> Come al solito, passeggiare per la libreria porta spesso a dei bei
>> risultati:
>>  https://docs.python.org/3.5/c-api/memory.html
>> spiega anche bene come si potrebbe fare.
>>
>>
> A me sembra proprio di no.
>
> Scusa... parliamoci chiaro. Diciamo che hai scritto un allocatore che
> lavora su un chunk di memoria condivisa.
> Che vuole anche dire condivisa fra piu' processi (se no non e'
> particolarmente interessante).
>
> Mi spieghi come hai intenzione di fare si che tutto questo non si rompa
> male *senza* usare lock?
>

Scrivendoci sopra solo quando NON ho altri processi che ci lavorano. Per
esempio lanciando
gli altri processi dopo averci scritto sopra, ed ovviamente non parlo
di allocare nello heap di python (faccio riferimento al primo esempio nella
pagina).
Mi rendo conto che è un lock logico ma funzionerebbe lo stesso.
Ci proverò e saprò dire come va.


>> Sembrerebbe anche qui:
>>
>> https://docs.python.org/3.5/library/multiprocessing.html#module-multiprocessing.sharedctypes
>>
>> Che era, in effetti, quel che cercavo.
>>
>
> Io continuo a credere che tu stia ficcandoti da solo in un bagno di sangue.
> Perche' sei convinto che la memoria condivisa ti *serva*?
>
>

mi cito: per vedere l'effetto che fa :-)

Nel senso che adesso NON ne ho bisogno, ma voglio provarlo per vedere SE
come e quando, prima o poi, mi converrebbe usarlo.

E grazie a tutti per le dritte ed i suggerimenti impliciti ed espliciti.

>
>

>

>> Di passaggio vedo che pickle è usato solo per Queue in code FIFO ma che
>> la Pipe sottostante non la usa.
>>
>
> Si, e' corretto. Il motivo e' che la pipe "astrae meno" e ti da
> fondamentalmente un'interfaccia a "byte".
> E apre tutto il problema di come separare i messaggi, cosa considerare un
> messaggio... nota che le pipe non sono multi reader/multi writer (a meno
> che non aggiungi tu sincronizzazione... che vuole dire che di fatto ti
> re-implementi le Queue -- nota che per vari motivi le Queue di mp hanno
> *anche* un thread per darti la semantica attesa).
>

Non ci pensavo proprio :-)

>
>  Io personalmente quello che spesso e' fare completamente a mano. Non
> trovo le pipe di mp particolarmente utili. In molti casi un socket unix
> domain a datagrammi e' proprio la cosa che vuoi, per dire.
>

Di nuovo grazie per la dritta: non ci avevo proprio pensato.

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

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.
> >
>
> Vedi shmget e mmap:
> https://trac.nginx.org/nginx/browser/nginx/src/os/unix/ngx_shmem.c
>
> Ma come ti ha già scritto Enrico, l'accesso diretto ad un area di
> memoria non è banale in Python, a meno di non usare tipi primitivi a
> dimensione fissa.
>
>
Come al solito, passeggiare per la libreria porta spesso a dei bei
risultati:
 https://docs.python.org/3.5/c-api/memory.html
spiega anche bene come si potrebbe fare.


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

Sembrerebbe anche qui:
https://docs.python.org/3.5/library/multiprocessing.html#module-multiprocessing.sharedctypes

Che era, in effetti, quel che cercavo.

Di passaggio vedo che pickle è usato solo per Queue in code FIFO ma che
la Pipe sottostante non la usa.

Ok, appena ho un po' di tempo libero mi ci metto a giocare per vedere
l'effetto che fa :-)

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

Re: [Python] Problemino Django e HTTPS

[alessandro medici]

2016-05-25 12:42 GMT+02:00 Carlos Catucci :

> Salve gente,
>
> sto cercando di far accedere al mio applicativo Djaongo tramite HTTPS.
> Nel config.py ho settato la chiave
>
> ...

> """
> Internal Server Error
>
> The server encountered an internal error or misconfiguration and was
> unable to complete your request.
>
> Please contact the server administrator at webmaster@localhost to
> inform them of the time this error occurred, and the actions you
> performed just before this error.
>
> More information about this error may be available in the server error log.
>
> 
> Apache/2.4.7 (Ubuntu) Server at inno Port 9443
>

boh, ci stavo cialtronando su qualche giorno addietro:

hai usato mod_wsgi per apache?


> """
> Guardo su /var/log/apache2/error.log e non c'e' nulla, su access.log trovo
>
> xxx.xxx.xxx.xxx - - [25/May/2016:12:29:36 +0200] "GET /favicon.ico
> HTTP/1.1" 500 996 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64;
> rv:46.0) Gecko/20100101 Firefox/46.0"
>
>
E solo un warning sul favicon: puoi anche fregartene è solo per la
mascherina a fianco del nome del sito.

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

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

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

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

Per il resto, e' un oggetto che riserva molte sorprese, e non del tipo
> divertente.
>
> Se hai un problema I/O bound guardati cose come gevent, tornado, il
> vecchio twisted o il nuovo asyncio.
>

concordo per asyncio, se del caso.


> Se hai un problema CPU bound... boh, fai offload a chi puoi. Numpy in
> certi casi. Se no a volte con un po' di attenzione si possono fare cose
> belline con multiprocessing. Poi per dire l'ultima volta che lo ho messo in
> produzione mi sono scritto a mano tutte le primitive di comunicazione fra
> processi, perche' le implementazioni di default di multiprocessing non
> facevano per me (semantica, + tirano su thread, + sono lente... etc etc
> etc). Questo non vuole dire che per te non andranno bene: probabilmente se
> sono ancora li, vuole dire che vanno bene per la maggior parte delle
> persone.
>

concordo anche qui.  In effetti stavo proprio pensando a casi specifici.
Proverò.

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

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

[alessandro medici]

Il giorno 21 maggio 2016 12:51, enrico franchi <enrico.fran...@gmail.com>
ha scritto:

>
>
> 2016-05-20 13:59 GMT+01:00 alessandro medici <alexxandro.med...@gmail.com>
> :
>
>>
>> - "multiprocessing" implica (a meno di eccezioni notevoli) "pickle di
>>> tutto"
>>>
>>
>> ? cioè i dati vengono trasmessi via pickle e non via puntatori? Sure?
>> O invece non ho capito cosa affermi? Sorry per la mia ignoranza, ma
>> sono anziano e con i capelli MOLTO grigi.
>>
>
> Non e' questione di ignoranza, basta rifletterci. Allora...
> multi-*processing*.
> Diciamo che e' sano assumere che siano piu' processi, ok? Quindi piu'
> processi hanno spazi di indirizzamento separati (visto che sono appunto
> processi multipli). Quindi... cosa se ne fa un processo di un puntatore a
> uno spazio di indirizzamento a cui non ha accesso? Diciamo nulla? Ah... ma
> c'e' la memoria condivisa... ecco, ora riflettiamo anche su questa cosa.
> Quando tu scrivi
>
> foo = Bar()
>
> tu stai dicendo a Python di creare un oggetto. Bene. Non gli stai dicendo
> dove crearlo. Il che vuole dire che non e' in memoria condivisa.
> L'alternativa sarebbe immaginare che Python ficcasse *tutto quanto* in
> memoria condivisa...
>

Già. Ho passato buona parte di ieri a guardarmi proprio il funzionamento
del Manager
dei processi. Ed ho lasciato a metà quello sul funzionamento di pickle.
Il ragionamento che fai fila, però... Mettiamola così: mi piacerebbe che
esistesse
un'opzione tale che permettesse di definire una variabile in uno spazio
condiviso ed
accessibile direttamente dai singoli processi. Starebbe poi a me gestirla.
E sicuramente
in molti casi sarebbe più veloce che impacchettare e spacchettare in giro
dati che, magari,
servono solo in lettura. Poi, se voglio darmi da solo la zappa sui piedi,
sono affari miei, in
pura logica Python :-)
Questo al di là della gestione bufferizzata dei dati elaborati da pickle e
dalle sue piccole
(tutto sommato) limitazioni.


> il che vorrebbe anche dire che ogni singolo pezzo di dato di Python
> dovrebbe avere qualche lock che lo protegge... altro che GIL: avremmo gia'
> threading granulare [ah, certo, potremmo anche immaginare che schiaffa
> tutto in memoria condivisa e c'e' un GIL su questo... ma allora fare
> multithreading o multiprocessing in Python dovrebbe essere uguale, cosa che
> no ne'].
>

No. Non occorrerebbe per tutto. Ovvio.

>
> Segue che ... no, non possono essere semplici puntatori. "Come" viene
> fatto non puo' essere derivato da principi primi. E si, effettivamente e'
> Pickle.
>
> Per inciso... presente il Manager di multiprocessing (e tutta la parte di
> "memoria condivisa" di multiprocessing)?
> Bene... di condiviso non c'e' nulla. Funziona con scambio di messaggi
> (cioe' piglia gli oggetti, li serializza e li spara in giro). Insomma, e'
> un giocattolino che e' comodo da usare e da ragionarsi come la peggiore
> delle memorie condivise ed e' veloce come il piu' lento dei message
> passing. Un win win... per i linguaggi concorrenti...
>

Già e vediamo se ho capito, allora, e uso come esempio proprio il
programmino nel sito che aggiorna il dizionario:

Lancio da processo padre il processo figlio, al quale vengono passati,
pickled via Manager, i dati
dei parametri, poi quando il figlio arriva al punto dell'aggiornamento del
dizionario il figlio
chiama il Manager che pickla i dati di nuovo, li torno al padre (sotto GIL
e quindi in lista d'attesa
se vi sono altri processi che vogliono fare la stessa cosa) che aggiorna il
dizionario e torna il controllo, sempre via Manager al figlio. Corretto?

Se è così ora affronterei un multiprocesso con le idee molto più chiare sul
cosa, quando, quanto
passare al processo stesso e sull'architettura che darei al soft.

Quindi grazie a tutti quelli che hanno scritto al riguardo: ho avuto le
risposte che cercavo.

:-)

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

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

[alessandro medici]

Il giorno 20 maggio 2016 16:42, Pietro Battiston <m...@pietrobattiston.it> ha
scritto:

> Il giorno ven, 20/05/2016 alle 16.26 +0200, alessandro medici ha
> scritto:
> ...
> > Qualche aiuto/commento? Per caso usi pickle per passare copie di
> > dati?
>
> Sorry, mi ero dimenticato di rispondere a questo.
>
> Non è purtroppo una mia scelta quella di usare pickle, ma parte del
> funzionamento di multiprocessing!
> Vedi ad esempio
> http://stackoverflow.com/questions/1816958/cant-pickle-type-instancemet
> hod-when-using-pythons-multiprocessing-pool-ma
> ... (non trovo al momento un riferimento chiaro nella documentazione).
>
...

qualcosina di utile qui, sul perché ed il percome:

https://www.chrisstucchio.com/blog/2013/why_not_python.html

Forse meglio gli interventi che l'articolo.

>
> Pietro
>

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

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

[alessandro medici]

Il giorno 20 maggio 2016 16:42, Pietro Battiston <m...@pietrobattiston.it> ha
scritto:

> Il giorno ven, 20/05/2016 alle 16.26 +0200, alessandro medici ha
> scritto:
> > Il giorno 20 maggio 2016 16:05, Pietro Battiston <ml@pietrobattiston.
> > it> ha scritto:
> >
> > >  > >  - "multiprocessing" implica (a meno di eccezioni notevoli)
> > > "pickle
> > > > > di
> > > > > tutto"
> > > > ? cioè i dati vengono trasmessi via pickle e non via puntatori?
> > > Sure?
> > > > O invece non ho capito cosa affermi? Sorry per la mia ignoranza,
> > > ma
> > > > sono anziano e con i capelli MOLTO grigi.
> > Qualche aiuto/commento? Per caso usi pickle per passare copie di
> > dati?
>
> Sorry, mi ero dimenticato di rispondere a questo.
>
> Non è purtroppo una mia scelta quella di usare pickle, ma parte del
> funzionamento di multiprocessing!
> Vedi ad esempio
> http://stackoverflow.com/questions/1816958/cant-pickle-type-instancemet
> hod-when-using-pythons-multiprocessing-pool-ma
> ... (non trovo al momento un riferimento chiaro nella documentazione).


Visto. Ed ho visto anche gli escamotages.

E', al solito, una questione di disegno: se hai bisogno di codice che agisca
veloce: poco da fare. Ma se hai bisogno di codice che re-agisca veloce
(in altre parole puoi lavorare prima sulle precondizioni ed il codice deve
solo esser reattivo ad un caso quasi-previsto) una factory del metodo che
ti serve potrebbe essere una buona soluzione. Capita. In tal caso pickle
potrebbe implementare solo il puntatore alla classe esterna.
(ma da andar a vedere se è vero :-)

Ve ne è un ottimo esempio nell'implementazione di asyncio in 3.4, non ho
avuto occasione di guardare se han cambiato qualcosa in 3.5.

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

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

[alessandro medici]

Il giorno 20 maggio 2016 16:05, Pietro Battiston  ha
scritto:

> >  - "multiprocessing" implica (a meno di eccezioni notevoli) "pickle
> > > di
> > > tutto"
> > ? cioè i dati vengono trasmessi via pickle e non via puntatori? Sure?
> > O invece non ho capito cosa affermi? Sorry per la mia ignoranza, ma
> > sono anziano e con i capelli MOLTO grigi.
>

Qualche aiuto/commento? Per caso usi pickle per passare copie di dati?

>
> Il dubbio che mi resta davanti a quei grafici è come sia possibile che
> passando da 1 a 2, o 3, core si ottenga una riduzione (piccola ma
> abbastanza evidente) del work time. Potrà essere dovuto al fatto che i
> vari processi fanno esattamente lo stesso lavoro e c'è una qualche
> forma di caching intelligente tra core?
>

Credo sia dovuto all'uso che fanno di ast. Questo w.e. speravo di avere
il tempo di dare un'occhiata ravvicinata al loro codice, ma è stata una
speranza
invana: mia morosa ha altri problemi :-(

Amen: altra cosa al domani.


> > > ovunque ci sia un array numpy), dask ( http://dask.pydata.org ;) mi
> > > sembra la salvezza (finora per quel che mi riguarda ci ho fatto
> > > solo
>
> Concordo. Ma dask è in un certo senso estremamente semplice. Se
> soddisfa le tue necessità e le tue necessità coinvolgono un array numpy
> grosso, le operazioni che fai saranno praticamente identiche
> all'utilizzo di numpy... tranne che saranno distribuite su tutto quel
> che ti pare.
> (A me poi interessa particolarmente il supporto per le strutture
> pandas)
>

Raro abbia necessità di calcoli complessi. Molto più spesso è solo gestione
di dati non omogenei. E, praticamente sempre non ho alcuna necessità di
scrivere codice che funzioni veloce, quanto di scrivere veloce del codice
che funzioni.

Quello che devo ancora capire è solo quale fetta delle mie necessità
> soddisfi!
>

Quella che ti serve al momento!  :-)


> Pietro
>

Alex

ps: sistu Veneto? Io di Padova: www.fsugpadova.org
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] anche questo è carino assai :-)

[alessandro medici]

Ne spiego il perché:

Da quando ho trovato questo suggerimento non ho mai usato quanto
suggerisce, ma in futuro, quando mi troverò di nuovo in un caso in cui
ho migliaia di chiamate a funzione e spesso in cicli di centinaia in cui
cambia solo un parametro, potrebbe essere una soluzione simpatica
per alleggerire il codice e, con poca spesa, velocizzarlo un poco.

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

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

[alessandro medici]

Il giorno 20 maggio 2016 15:02, Marco Beri <marcob...@gmail.com> ha scritto:

> 2016-05-20 14:59 GMT+02:00 alessandro medici <alexxandro.med...@gmail.com>
> :
>>
>> Toh: un fiorire di suggerimenti :-)
>>
>
> Vero. Amo questa lista.
>
> Ciao.
> Marco.
>

Anch'io ho questa passione fetish. :-)

Per tornare sul tema:
Mi piace anche l'uso che hanno fatto di ast.
Ma perché mai hanno purgato il codice di tutti i commenti?
Mi sa che mi giocherò di più di un w.e. :-(

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

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

[alessandro medici]

Il giorno 20 maggio 2016 14:12, Pietro Battiston  ha
scritto:

> Il giorno ven, 20/05/2016 alle 11.56 +0200, Marco Beri ha scritto:
> > 2016-05-20 11:46 GMT+02:00 Marco Beri :
> > > 2016-05-20 11:39 GMT+02:00 Strap :
> > > > Ciao a tutti,
> > > > per curiosità, ma soprattutto per vedere l'effetto che fa :-P,
> > > > condivido con
> > > > voi il seguente link: https://www.peterbe.com/plog/deco
> > > Bello! Certo che tre sleep(5) in parallelo vanno bene.
> > > Vedo meno bene tre loop che fanno robe cpu intensive :-)
> > >
> > Ho parlato troppo presto... Poi nel resto dell'articolo fa degli
> > esempi molto più fighi!
> >
>
> Beh, l'obiezione non era insensata...
> https://www.peterbe.com/plog/time-to-do-concurrent-cpu-bound-work
> menziona un calo di efficienza (ovviamente in termini di tempo di
> calcolo totale) notevole.
>
> Le due cose che _non_ menziona, e che credo possano essere rilevanti,
> sono:
> - il suo Macbook Pro ha (credo) 4 core fisici: se ne vede 8 è grazie
> all'hyperthreading, che però è meno effettivo (vado a braccio su cose
> lette qua e là) se tutti i processi "fanno la stessa cosa" (ma è
> curioso che comunque da 2 a 3 e da 3 a 4 processi un calo netto ci sia
> già)
>

mica tanto curioso: anche il sistema vuol dire la sua, e se gli chiedi
tutti i core te li concede 'a singhiozzo'. Già imbattuto, e spesso, nel
caso.


> - "multiprocessing" implica (a meno di eccezioni notevoli) "pickle di
> tutto"
>

? cioè i dati vengono trasmessi via pickle e non via puntatori? Sure?
O invece non ho capito cosa affermi? Sorry per la mia ignoranza, ma
sono anziano e con i capelli MOLTO grigi.

>
> (Per la cronaca: ci infila un paio di panzane, tipo che il secondo
> grafico dimostri "The individual work withing each process is not
> generally slowed down much", e che la curva blu sia "reverse
> logarithmic")
>

Lo farò girare, ma in ogni caso il primo giudizio è solo soggettivo:
conta poco. Per la seconda curva hai ragione: sembra più che altro
una semplice proporzionalità inversa al numero dei thread fino ai 3.
Oltre, secondo me, si nota l'effetto sistema.

>
> Mi stupisce peraltro un po' che pydron, la libreria a cui i creatori di
> deco dicono di ispirarsi, sia stata pensata per l'astrofisica... perché
> per quel che riguarda le applicazioni scientifiche (o più precisamente,
> ovunque ci sia un array numpy), dask ( http://dask.pydata.org ) mi
> sembra la salvezza (finora per quel che mi riguarda ci ho fatto solo
> prove molto semplici, ma mi sembra che batta ad occhi chiusi un
> approccio standard con multiprocessing o un suo wrapper).,
>

Toh: un fiorire di suggerimenti :-) Bene, sarò occupato anche questo w.e.
:-)

Ma in realtà mi piace la semplicità dell'approccio. Il che vale tempo
nello sviluppare. L'unica cosa che non ho davvero capito è quanto sia
thread-safe maneggiare un dizionario in quel modo. Ci giocherò.


> Pietro
>

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

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

[alessandro medici]

Assai divertente.

Ma noto che nell'ultimo esempio in https://www.peterbe.com/plog/deco
inserisce
una nuova voce (sicuramente univoca) in un dizionario creato esternamente
(io non
mi ero mai azzardato a farlo in un thread, solo a modificare il valore di
una chiave
già esistente).

Ricordo al riguardo che mi è stato obbiettato che la cosa funzionava solo
per una
specifica implementazione di Python. Non sono abbastanza ferrato per
giudicare
al riguardo. Qualcuno che ne sa qualcosa potrebbe dire la sua: Trovo questo
deco
estremamente interessante per le possibilità che offre di scappare a GIL in
alcuni casi.

Grazie in generale e tia in particolare se qualcuno risponde :-)
​
A
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] anche questo è carino assai :-)

[alessandro medici]

http://mathamy.com/python-wats-mutable-default-arguments.html
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Aiuto, mi incarto con python 3.4 e gli import!

[alessandro medici]

Il giorno 4 marzo 2016 09:46, germano carella 
ha scritto:

> ...
> Ho installato il package in python 3.4 con pip.
> pip install accessible_output, successful!
> Ottimo, fico...
> ...
>

Non so che sistema usi: non conosco nulla di windows, ma se installi su una
Debian (e suppongo tutte le sue derivate, varie ubuntu comprese) pip va
specificato:

 pip3 install accessible_output

cioè devi usare la versione per python3 che è, appunto pip3, con pip e
basta installi la versione 2.7 ed, ovviamente, non si troverà nel path di
python3. Quindi import non la vede.

Bye!

>
> ___
> 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] AA Cercasi Pythonisti Padovani !

[alessandro medici]

Noi ci si ritrova in sei sette due/tre volte al mese il sabato pomeriggio
nella sede del fsug padova (www.fsugpadova.org).

Temi diversi e vari, tecniche d'uso, idee e sviluppo.
Il tutto con Python, ovvio.

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

Re: [Python] PEP 0484 - Dubbio

[alessandro medici]

ma utili al debugging e dannatamente utili ai compilatori. Se li usassero.

my 1 cent :-)

Il giorno 25 febbraio 2016 23:15, Roberto Polli  ha
scritto:

> Il 24 febbraio 2016 17:29, Carlo Miron  ha scritto:
> >> Ma a livello semantico le 'Type Hints' non hanno alcun effetto?
>
> Sono Hints, appunto.
>
> Pax,
> R.
> ___
> 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] aggiungere o distruggere una locked item in un dict mentre un'altro thread o asyncio lo legge/scrive per un'altra item?

[alessandro medici]

Ci ho messo un po', ma in effetti è possibile leggere, scrivere, rimuovere
ed aggiungere chiavi e valori su un dizionario non locked ed in comune a
diversi thread, indipendentemente dai valori impostati
con sys.setcheckinterval(), o almeno con i valori con cui ho provato e con
diverse distribuzioni di frequenza delle operazioni (alle righe 105 e 109).

128,64,32,16,8,4,2,1 il default per python3.5.1 nella mia debian è 100.

l'unica ovvia accortezza è evitare di operare in contemporanea sulla stessa
chiave. In pratica è un dizionario con accesso thread-safe-like con un lock
esterno alle singole voci. Per risolvermi il problema però ho messo su un
accrocchio che ha l'unica qualità di funzionare.

Ciao Alex
ps: se non mi è scappata qualche cavolata qui sotto :-)
http://pastebin.com/xQZPTUtg
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] aggiungere o distruggere una locked item in un dict mentre un'altro thread o asyncio lo legge/scrive per un'altra item?

[alessandro medici]

Dimenticavo:

ho provato anche con 8 thread contemporanei, ma la macchina diventa,
ovviamente, un carrettone, fatto girare su una debian unstable:

Python 3.5.1+ (default, Jan 13 2016, 15:09:18)
[GCC 5.3.1 20160101] on del, Threaded
>>>  1
​
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] aggiungere o distruggere una locked item in un dict mentre un'altro thread o asyncio lo legge/scrive per un'altra item?

[alessandro medici]

ok,

http://pastebin.com/SL4cJ0vv
​
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] aggiungere o distruggere una locked item in un dict mentre un'altro thread o asyncio lo legge/scrive per un'altra item?

[alessandro medici]

L'esempio che hai fatto non è quello che intendevo io: accedi a due voci
contemporaneamente dello stesso dizionario nello stesso thread. Comunque
proverò.

In ogni caso a me risulta che Gil rilascia i thread ogni 'gruppo' di
istruzioni bytecode, non ogni singola istruzione. In altre parole
sovrascrivere una voce di un dizionario è, per quel che riguarda python,
una istruzione atomica. La cosa è evidente se cerchi di scrivere sullo
stesso terminale da ogni thread: quel che appare è un guazzabuglio confuso
ma è anche evidente dal risultato degli script che ho scritto.

O, quantomeno, la cosa funziona: mi son fatto diversi script in cui ogni
thread modifica/usa/cancella/trattiene una voce (con un lock non atomico di
controllo di accesso) in un dizionario e gli altri fanno quello che
vogliono sulle ALTRE voci con le stesse regole. Ogni voce punta ad una voce
univoca di un altro dizionario senza lock che viene cancellata/riscritta.

Funzionano perfettamente senza problemi, almeno per quella decina di
milioni di volte per cui li ho fatti girare: direi che si può benissimo
farlo anche se sono certo del reale perché.

Mah!
:-)
​
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] aggiungere o distruggere una locked item in un dict mentre un'altro thread o asyncio lo legge/scrive per un'altra item?

[alessandro medici]

quasi RISOLTO SOLVED

banale, mi sono fatto uno script che testa un dizionario di 10 voci con 8
thread,  e che al dizionario gliene fanno di cote e di crude su un quadcore
abbastanza veloce, il tutto per un milione di volte in 60 secondi e la
conclusione è che si: sui dizionari di può fare quel che si vuole alle
ALTRE voci, anche distruggerle in altri thread. Python non fa una piega.
Non ho nemmeno utilizzato un context manager, solo una semplice flag come
semaforo della voce che intendevo cambiare.

Il 'quasi' è perchè non ne so il perché. E la cosa mi irrita.

Buona notte a tutti.
​
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] aggiungere o distruggere una locked item in un dict mentre un'altro thread o asyncio lo legge/scrive per un'altra item?

[alessandro medici]

è bene saperlo. Null'altro :-)​
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] aggiungere o distruggere una locked item in un dict mentre un'altro thread o asyncio lo legge/scrive per un'altra item?

[alessandro medici]

Ah. Ho letto e fatto girare codice con tkinter su asyncio. Va bene :-)
Il 11/feb/2016 19:16, "enrico franchi" <enrico.fran...@gmail.com> ha
scritto:

>
> 2016-02-11 18:07 GMT+00:00 alessandro medici <alexxandro.med...@gmail.com>
> :
>
>> Si, in effetti uso asyncio in un thread, ma altri thread lavorano al
>> contempo sugli stessi dizionari e mi risulta che che Gil si sganci quando
>> entra in un thread.
>>
>
> Ma hai una buona ragione per andare di multithreading in Python (yet to be
> found) *e* infilare su un thread un runloop di asyncio?
>
> No aspetta... il problema e' che hai una GUI; in questo caso vedo del
> senso. Per tutto il resto.. no.
>
> Spiego meglio: i thread in Python fanno grosso modo cacare (sentiti libero
> di riformulare come: "i thread fanno cacare, specie in Python"). L'unica
> cosa per cui non sono completamente fallimentari e' usarli per fare I/O --
> visto che per cose CPU bound non funzionano affatto come ci si aspetta --.
> E guarda caso e' anche la cosa che dovrebbe fare bene asyncio (i/o, that
> is). Il che vuole dire che se devi solo fare I/O, allora potresti usare
> solo asyncio. Se devi fare roba CPU bound, i thread non sono la soluzione.
>
> A meno che per qualche motivo non hai da integrare runloop misti (gui)...
> che alcuni framework asincroni ti consentono di fare abbastanza facilmente
> (Twisted), ma che magari asyncio non consente di fare in modo altrettanto
> semplice.
>
>
> --
> .
> ..: -enrico-
>
> ___
> 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] aggiungere o distruggere una locked item in un dict mentre un'altro thread o asyncio lo legge/scrive per un'altra item?

[alessandro medici]

In effetti a parte la gui non mi serve. Davvero. E concordo sul giudizio
escrementizio. Epperò vorrei lo stesso trovare la risposta :-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] aggiungere o distruggere una locked item in un dict mentre un'altro thread o asyncio lo legge/scrive per un'altra item?

[alessandro medici]

Intanto grazie mille della risposta cortese e soprattutto davvero molto
utile in particolare ed in generale.

Peccato solo che manchi il caso dict.__delitem__(item)

Si, in effetti uso asyncio in un thread, ma altri thread lavorano al
contempo sugli stessi dizionari e mi risulta che che Gil si sganci quando
entra in un thread.

Per locked intendo l'usare una context manager (di massima
multiprocessing.Lock: è atomica e perfettamente with compatibile :-) ma
riferita solo all'item specifica del dizionario su cui il thread sta
lavorando, con questo è ovvio che potrei segnalare a tutti i thread di
lasciare in pace i dizionari ove altri thread stanno lavorando, ma il tutto
mi rallenterebbe troppo il flusso del programma.

Pensavo quindi di usare il lock solo come indicatore di non lavorare su
quella singola item di ogni specifico dizionario. Ed è per questo che
volevo sapere cosa succede quando un thread fa una richiesta sul valore di
una item mentre un altro thread ne modifica (credo che in questo caso non
abbia importanza) o ne cancella o inserisce un'altra (e qui la cosa si fa
più preoccupante. Ovvio che non userò iteratori su quei dizionari: mi
incazzerei anch'io se mi togliessero la sedia dal sedere mentre ci sto
seduto sopra :-)

In questo momento quindi mi stavo scrivendo un programma che andasse a
vedere in pratica cosa potrebbe succedere: l'idea sarebbe forzare
collisioni sullo stesso dizionario di solo sei item mettendo su quattro
thread che random leggono/scrivono/cancellano/aggiungono.

In effetti però, sarebbe bello se qualcuno sapesse già la risposta e magari
anche il perché della stessa.

E grazie di nuovo.
​
Alex
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] aggiungere o distruggere una locked item in un dict mentre un'altro thread o asyncio lo legge/scrive per un'altra item?

[alessandro medici]

ecco, mi domandavo se sia solo insano o sicuro.

Chiedo venia, ma l'acqua calda questa volta non sono riuscito a trovarla.

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