Re: [Python] Fwd: Cosa sbaglio

[enrico franchi]

2016-05-30 21:16 GMT+01:00 Piacenza Federico :

> Aiutatemi per favore, proprio non capisco cosa sbaglio.
>

E' una faq... leggiti la PEP8. Detto questo, secondo me devi chiarirti come
funziona l'assegnamento (e il passaggio di parametri) in Python...

0. cosa stampa esattamente (ovvero, quante volte stampa 'called g') questo
programma?
def g():
  print 'called g'
  return []

def f(b=g()):
  b.append(1)

g()
g()

1. secondo te cosa fa

a = []
b = a
a.append(1)
print b

2. secondo te cosa fa

def f(b):
  b.append(1)

a = []
f(a)
print a

3. cosa fa

a = []

def f(b=a):
  b.append(1)

f(a)
print a

4. perche' 3 dovrebbe essere diverso da 2?
5. perche' 3. dovrebbe essere diverso da

def f(b=[]):
  b.append(1)

f()

... eh... non so come fartelo printare (senza cambiare l'eserczio o fare
dei magheggi che non vuoi vedere).

Beh, dai, se siamo arrivati fin qui... sappiamo che l'oggetto che e' stato
passato ad f quando l'abbiamo invocata (senza argoment) sara' [1, ].
E guarda 0...







-- 
.
..: -enrico-
___
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,

[enrico franchi]

2016-05-27 22:52 GMT+01:00 alessandro medici :

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

E, come si diceva, se stai usando massicciamente dizionari in shared memory
stai sbagliando piu' che qualcosa. Tipo hai probabilmente sbagliato
completamente il linguaggio e/o l'architettura.


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

???

Ma ti e' chiaro che il 95% della gente che usa multiprocessing lo fa in
modo completamente diverso da come lo fai tu? Cioe' io ho visto delle gran
chiamate a Process (che ti lancia un nuovo processo che esegue una funzione
di tua scelta con argomenti di tua scelta. Dopo di che se devi continuare a
comunicare metterai in piedi qualche forma di IPC sensata fra processi. E
ancora di piu' la gente usa Pool (che e' una cattiva idea sotto tanti punti
di vista), ma formalmente ti da il concetto di "pool di worker" cui
sottometti task che loro eseguono e tanti saluti.

Poi e' chiaro, sei liberissimo di progettare architetture come si faceva
prima che ci si rendesse conto che non e' una buona idea. Ma non ti stupire
se la gente ti dice che non e' una buona idea. Appunto perche' negli ultimi
20 anni ci si e' sempre piu' reso conto che *non* e' una buona idea.

Aggiungo... perfino nel mondo Java, che era l'impero della memoria
condivisa, la gente che scrive Java per davvero si e' spostata altrove.
Buona parte delle feature dei nuovi Java sono in favore di avere pool di
task che fanno cose, eventualmente con costrutti relativamente funzionali
come i futures. Tipicamente cerchi di limitare al massimo l'uso di lock e
di memoria condivisa perche' *non* scalano.

E quindi hai i vari bus ad eventi dentro Guava/Guice, hai vari sistemi ad
attori (tipo Akka, che viene da scala, ma insomma... si usa anche in Java).
Hai Scala e Clojure (entrambi sulla JVM) ed entrambi cercano di promuovere
un diverso modo di fare concorrenza.

Tra l'altro in Python quando metti su un'architettura spesso passi da
Celery o magari da rq... e ti muovi proprio nella direzione di avere task
che vengono fatti girare su pool di worker. E il motivo per cui lo si fa e'
che multiprocessing non ti da molto a livello di architettura; e' comodo da
usare per cose semplici, ma poi gli manca parecchia colla per andare in
produzione.


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

Diciamo cosi'... tu consisti ad insistere su sta cosa della memoria
condivisa come se fosse un problema. Non e' un problema. Tanto per dirne
una, se vai a memoria condivisa non riuscirai *mai* a fare scalare la tua
applicazione per davvero. Per cui normalmente la gente nel 2016 *non* usa
memoria condivisa come si faceva negli anni 90. Se hai memoria condivisa,
vuoi che sia estremamente locale per determinate cose e che tipicamente non
sia come comunicano i pezzi della tua applicazione (per mille motivi). Non
si scrive cosi' il codice.

Come dicevo altrove... ci sono eccezioni. Per esempio se stai scrivendo una
pipeline di processamento audio dentro il kernel. Ma in questo caso non
ragioni in termini di processi e non lo fai in Python.

Se stai lavorando in Python su una cosa nella quale le performance sono
critiche:
1. di solito si parla di performance di I/O
2. di solito non puoi permetterti di non scalare orizzontalmente.

E in questi casi la soluzione (1) non passa da multiprocessing (se non,
eventualmente, tangentalmente) e (2) non vuoi usare la memoria condivisa.


>
> 17.2.1.5. Sharing state between processes¶
> 
> 

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

[enrico franchi]

2016-05-27 13:54 GMT+01:00 Roberto Polli :

> Con un broker ;)
>
> https://en.wikipedia.org/wiki/Software_transactional_memory
>

Dai, sfortunatamente non puo' funzionare. Cioe', STM funziona. Non funziona
per questo use-case. Tanto per dirne una, ci sono seri problemi su come
infilare quasi qualunque tipo di I/O in sto modello. Tu qui ti troveresti a
volere fare girare Python arbitrario dentro transazioni.

Che voglio dire... ci stiamo arrivando. O meglio, Armin Rigo ci sta
arrivando... ed e' tipo in completa avanguardia (ovvero, quelli che ci
hanno provato prima hanno fallito per vari motivi).


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

Re: [Python] Insiemi e multiprocessor.

[enrico franchi]

2016-05-27 16:22 GMT+01:00 alessandro medici :

> Credo intendesse pleonastiche.
>

No, intendevo non desiderabili. Pleonastiche sarebbe meglio.
Il problema e' che se scrivi set([f(x) for x in xs]) prima costruisci
interamente la lista, poi la passi a set.

-- 
.
..: -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-27 13:41 GMT+01:00 enrico franchi <enrico.fran...@gmail.com>:

> Ok... sto barando. Potresti avere questo oggetto "magico" nell'area
> condivisa e poi passarti oggettini che sono solo riferimenti a
> quell'oggetto (ma che a loro volta non sono condivisi).
>

Ah, ça va sans dire, questo oggetto sarebbe eterno. Non ci puoi fare sopra
reference counting. Non puoi sapere chi lo sta usando. Vuole dire che nasce
e dura... finche' tutta la pagina non viene deallocata.

Che magari finche' e' *un* oggetto puoi anche permetterlo. Ma non mi e'
chiara quale sarebbe l'utilita'.


-- 
.
..: -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-25 18:02 GMT+01:00 alessandro medici :

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

Scusa, e come fai a sapere che gli altri processi *non* 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).
>

Quindi stiamo parlando di un oggetto che scrivi in questa area condivisa
(qui c'e' un solo processo).
Poi crei altri processi, che pero' non possono fare *nulla* con
quell'oggetto. Perche'? Perche' anche semplicemente fare f(obj) ha effetto
sul reference counting.
Ma anche o = obj.

Quindi gli altri processi non possono manco referenziare sto oggetto; non
lo possono vedere.

Ok... sto barando. Potresti avere questo oggetto "magico" nell'area
condivisa e poi passarti oggettini che sono solo riferimenti a
quell'oggetto (ma che a loro volta non sono condivisi).

Il problema sarebbe che non hai la semantica di Python (e.g., non puoi
aggiungere, togliere un attributo...). Sarebbe un oggetto puramente
immutabile. Immutabilissimo.
E allora quale e' il vantaggio di averlo cacciato in memoria condivisa?
Puoi fare cose piu' semplici.

E non puoi nemmeno avere cose tipo il creatore modifica. Perche'? Perche'
dovresti garantire che tutte le modifiche sono atomiche. Ora, siccome non
hai lock, non puoi "rendere atomica dal punto di vista di chi legge".
Puoi *solo* usare cose atomiche per davvero. Tipo, non puoi facilmente
avere un dizionario Python... in Python molte operazioni sui dizionari sono
atomiche, perche' hai il GIL. Ma in questo caso... il GIL non ce lo hai.
Quindi

Quindi per fare qualcosa di vagamente utile dovresti risolvere gli stessi
problemi che devono risolvere quelli che vogliono levare il GIL.

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.


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

Re: [Python] Insiemi e multiprocessor.

[enrico franchi]

2016-05-26 17:09 GMT+01:00 alessandro medici :

> In effetti pensavo a qualcosa di assai più complesso ma, ovvio,
>

Io pero' sono un po' confuso. Ovvero, capisco la specifica "generica"
voglio qualcosa che si comporti come gli insiemi, ma... il punto e' che
nella pratica e' qualcosa che non vuoi (o ci sono gia' cose che fanno
quello che ti serve).

Ovvero... cosa e' un insieme? In matematica un insieme e' *semplicemente*
una collezione di "oggetti" (ovviamente non parliamo in questo caso di
programmazione ad oggetti... parliamo di oggetti matematici).
Questo e' un insieme. Niente di piu', niente di meno.

Quindi poi si apre la questione di "come specifico un insieme"? E veniamo
appunto alla descrizione intensionale o estensionale. Ma questo non e'
parte della *definizione* di insieme (ovvero del concetto di insieme), ma
della descrizione di uno specifico insieme. Sono solo modi di specificare
insiemi.

Ma la faccenda fondamentale e' che in matematica non c'e' reale differenza
fra manipolare enti finiti ed infiniti. Esattamente come in matematica non
ci sono grossi problemi ad avere teoremi "di esistenza". Poi certo, c'e'
tutta una polemica interna verso teoremi non costruzionisti... ma appunto,
la matematica va avanti. L'informatica, invece, ha grosse difficolta' con
cose non costruzioniste. Perche' vuole dire che non abbiamo l'algoritmo:
sappiamo che una certa cosa esiste, ma non sappiamo calcolarla. Tutto
questo e' anche legato (ci arriviamo dopo) al concetto di
turing-calcolabile.

Ora... per un po' mi sono occupato di programmazione logica. E tutto questo
discorso e' terribilmente relato a cose come assunzione di mondo
chiuso/mondo aperto (OWA/CWA) e alla negazione come fallimento (NAF) e alle
logiche non-monotone. E questi sono problemi di ricerca *molto* sentiti.
Perche' appunto... sappiamo fare linguaggi di programmazione logici che
fanno CWA... ma per avere NAF (che e' relativamente comoda) si esce dalla
logica del primo-ordine (tipo in Prolog). Nota anche che questa parte di
Prolog e' fuori dalla parte strettamente dichiarativa di Prolog e diventa
invece procedurale.

Ora perche' tutto sto pappardello? Per dire che dimenticati Python (per
semplicita'). Tutto questo discorso degli insiemi, fallo in Prolog. Fallo
in Prolog perche' Prolog *li ha*, di fatto -- anche se non nella forma che
ti aspetti --. Poi capisci quali sono le limitazioni che Prolog ti da su
sta roba (niente affatto banali). Tutto questo puoi farlo in modo
"relativamente semplice" anche in Python -- relativamente semplice vuole
dire che in pratica devi scrivere un motore grosso modo equivalente a
Prolog... il che vuole dire che si puo' fare e si sa come farlo, non che
sia effettivamente rapido da fare --.

Ecco... e scoprirai che il concetto di insieme in Prolog e' comunque
sostanzialmente diverso dal concetto "intuitivo" di insieme che hai (ed e'
diverso pure dal concetto di insieme della logica matematica -- ricordiamo
che prolog implementa "completamente" la first-order logic, ma di fatto ha
bisogno di features extra-logiche, che diventano anche procedurali -- per
fare il resto, fra cui naf, che appunto e' importante parte del discorso).

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.

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.

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 

Re: [Python] Insiemi e multiprocessor.

[enrico franchi]

2016-05-26 16:21 GMT+01:00 Pietro Battiston :

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

Le quadre sono non desiderabili in questo.


-- 
.
..: -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-25 17:07 GMT+01:00 alessandro medici :

>
>> 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?
Che ok... alcune cose possono essere fatte con CAS (tipo i reference
counters); ma, come dicevo, CAS funziona bene quando hai poche scritture e
tante letture. Mentre qui hai un numero relativamente bilanciato delle due
cose. E comunque questo vorrebbe dire anche cambiare l'implementazione di
Object (IIRC non usa roba CAS). Ma le altre?





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

Io continuo a credere che tu stia ficcandoti da solo in un bagno di sangue.
Perche' sei convinto che la memoria condivisa ti *serva*?


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

 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.

Ma insomma... c'e' un po' da capire cosa ti serve, ma in generale non e'
complicato da implementare.



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

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

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

[enrico franchi]

2016-05-21 13:24 GMT+01:00 alessandro medici <alexxandro.med...@gmail.com>:

>
>
> 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 mio consiglio e' di lasciare perdere quella parte di multiprocessing (a
dire il vero... io suggerirei di pensarci sopra 80 volte prima di fare roba
vera con multiprocessing -- poi ne parliamo --.

Non vuoi usare qualcosa che sia scomodo e bug prone come la memoria
condivisa, ma con le performance del message passing (anzi, sinceramente,
con le performance da fanalino di coda del message passing, visto che altre
implementazioni di concetti simili sono molto piu' efficienti).


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

Si beh... come dire. Ora io capisco che a te piacerebbe questa feature. Io
posso dirti che *credi* che ti piacerebbe. 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).

Detto questo, sarebbe una feature assolutamente complicatissima da
implementare e che costringerebbe a fare andare tutto come una lumaca e/o a
rompere completamente l'astrazione di Python.

1. Python non ha il concetto di "area di memoria". Costruisci un oggetto.
Python ci pensa. Qui tu dovresti in qualche modo dire a Python che un certo
oggetto deve essere in un'area di memoria condivisa.

2. Come lo facciamo? O lo facciamo in modo implicito (che e' ancora meno
banale) oppure inventiamo qualcosa tipo... boh

Foo.shared(...)

che ha la stessa semantica di un normale Foo(...) ma mette le cose in
memoria condivisa.

Bene: nell'esatto istante in cui tu scrivi quella cosa, vuole dire che un
bel po' di roba viene schiaffata in memoria condivisa. Per esempio
l'oggetto classe Foo deve finirci. Ma non solo... ci deve finire qualunque
oggetto nell'MRO di Foo. E stiamo cominciando a tirarci dietro parecchia
roba.

Pero' aspetta... magari io avevo da qualche parte una roba come:

class Foo(object):
def __init__(self):
self.bar = Bar()

Ecco, l'oggetto che stiamo assegnando a self.bar deve pure finire anche lui
in questa memoria condivisa. Lui, la sua classe e tutti i suoi antenati e
tutti gli oggetti che entrano a fare parte dell'istanza (e cosi'
ricorsivamente).

Ora... capisci che e' un bel po' di roba.

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

Bene... in un caso stiamo replica

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

[enrico franchi]

2016-05-20 18:48 GMT+01:00 alessandro medici :

> https://www.chrisstucchio.com/blog/2013/why_not_python.html
>
> Forse meglio gli interventi che l'articolo.
>

+1

Il tizio ha ragione su alcuni punti, ma le argomentazioni che porta sono
spesso del tipo ho un martello, quindi e' tutto un chiodo.


-- 
.
..: -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-20 13:59 GMT+01:00 alessandro medici :

>
> - "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... 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'].

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




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

Re: [Python] __debug__ e EAFP

[enrico franchi]

2016-05-10 16:56 GMT+01:00 Pietro Battiston :

> Capisco. Beh, d'ora in poi lo utilizzerò solo come programmazione
> difensiva, ad esempio iniziando ogni mio listato con
>
> assert(__debug__)
>

Capisco la battuta, ma se e' non e' una battuta, spero di non dovere mai
usare il tuo codice, visto che non potrei farlo funzionare.
Oggettivamente non e' troppo sensato fare girare il codice in produzione in
modalita' debug, poi fai te. ;)
Poi spesso si fa, figuriamoci. Ma non poterlo fare, potrebbe risultare in
problemi.

E detto fra noi... ma veramente vogliamo usare assert come *controllo di
flusso*?

Cioe'... mi passi una lista vuota invece che una piena? AssertionError.
Mi passi un intero invece di una stringa? AssertionError.
Una chiamata http mi torna 503? AssertionError.

E poi chi lo debugga sto coso?



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

Re: [Python] Gestione checkbox

[enrico franchi]

2016-05-05 9:10 GMT+01:00 Daniele Alerni :

dando type(a[Fid]) mi aspettavo che mi ritornasse un oggetto checkbutton
> invece mi ritorna
>

E *perche'* ti aspetti che type(a[Fid]) ti ritorni un oggetto checkbutton?
Hai provato a leggere la documentazione di type per capire cosa fa?
Hint, sara' mai che *type* di un oggetto ti ritorna il *tipo* dell'oggetto?
Cosi', wild guess...


> Non ne capisco il significato,forse l'errore è in come creo i bottoni ?
>
>>
L'errore e' che stai andando completamente a casaccio. Meta' dei problemi
in questo thread non sarebbero manco sorti se avessi letto la
documentazione.
Poi voglio dire, procedi come ti pare, ma mi sembra chiaro che questo
approccio "scrivo istruzioni sperando che funzionino, poi chiedo" non ti
sta portando troppo vicino al tuo obiettivo.

Perche' non provare un approccio tipo: leggo la documentazione della roba
che uso, guardo gli esempi *criticamente* (perche' a questo punto posso
capirli), scrivo il mio codice, se ho problemi posso fare domande precise e
puntuali che otterranno risposte precise e puntuali e fatto quello che devo
mi vado a bere una birra con gli amici?

Detto questo... la "soluzione" a tutti questi problemi di "dove metto i
dati" si chiama MVC. Altra roba da studiare.
E ti anticipo... non e' banale mappare la teoria sulla pratica. Ma d'altra
parte quello e' cio' che ti serve per semplificarti la vita.

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

Re: [Python] OT: Imparare un altro linguaggio

[enrico franchi]

2016-05-03 21:42 GMT+01:00 Manlio Perillo :

>
> In realtà la puoi "emulare" usando unsafe e  uintptr.
> Ma ci sono delle limitazioni (dovute al garbage collector) che la
> rendono poco pratica.
> Vedi https://golang.org/pkg/unsafe/#Pointer, punto 3.


Si, certo. Puoi girarci intorno. Con cura. Come e' giusto.
Ad ogni modo, se vuoi, fa il suo mestiere, ma non incoraggia ad usare
questo a meno che non sia assolutamente necessario.


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

Re: [Python] Info sulla mailing-Risposta

[enrico franchi]

2016-04-28 21:32 GMT+01:00 Gollum1 :

> Dai... Non è vero... sono buono io... in fondo... molto in fondo...
>

Si, ma almeno tu, quota per bene! :)


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

Re: [Python] OT: Imparare un altro linguaggio

[enrico franchi]

2016-05-03 20:39 GMT+01:00 Giovanni Porcari :

> Sempre un piacere leggerti :)
>

:)


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

Re: [Python] OT: Imparare un altro linguaggio

[enrico franchi]

2016-04-27 12:17 GMT+01:00 Alessandro Re :

>
> Sì, intendevo più quello che i puntatori in sé. Anche se, se non
> sbaglio, l'aritmetica dei puntatori manca in Go, e quella la trovo
> divertente in sé :)
>

Si, l'aritmetica dei puntatori manca. E meno male... molto comoda se
proprio vuoi lavorare con la memoria a basso livello. Ma preclude un sacco
di cose carine (e oltretutto e' grossissima fonte di bachi).


> > Si alla programmazione funzionale "pura". Lisp lo definirei tutto meno
> che
> > "funzionale puro". Cioe', puoi limitarti ad un sottoinsieme "puro" di
> Lisp,
> [cut]
>
> ahah su questo devo semplicemente farmi da parte: non ho tutta
> l'esperienza che hai tu a riguardo, e mi sono dovuto limitare ai pochi
> linguaggi che ho usato :) Ricordo però che lisp e scheme li ho
> studiati in modo puramente funzionale.


Ma figurati! :) Certo puoi restringerti alle parti funzionali di lisp (o
evitare le parti, molto minori, non funzionali di scheme). Funziona
benissimo per imparare. Il problema e' che ovviamente il codice che si
trova in giro (e che a volte si deve scrivere) deve usare al meglio la
piattaforma. In questo senso, sebbene Lisp sia un linguaggio funzionale, e'
molto ibrido (per moltissimi motivi).

Ahah interessante... E mi sentirei di concordare, se solo non avessi
> il dubbio perenne di non aver capito qual è il modo giusto di usare go
>

Boh, a me viene naturale. Cioe', magari non mi viene giusto. ;)
Diciamo che mi piace quello che viene e mi viene facile scriverlo.


> :) Hai libri consigliati a tal proposito? Donovan & Kernighan?
>

Quello e' un ottimo punto di partenza. Come al solito chiaro, breve,
corretto ed efficace. E quando /Kernighan/ puoi anche accaderti che quello
che scrivi in un libro tu finisce per venire fatto.

Poi ci sono altre opinioni (bellissimo un post recentissimo -- giorni -- di
Cheney sulla gestione degli errori). Ma in generale direi che quello e' il
riferimento.


> >> > Poi oh, vedi te cosa vuoi fartene :) Se devi cercarti un lavoro...
> >> > Andrei su C/C++/Java.
> >
> > Io direi di no. C e' soprattutto embedded. C++ si trova da lavorare ma e'
> > molto specialistico. Java e' un mercato agguerrito. I posti di lavoro
> > interessanti li pigliano la gente *davvero* sveglia o davvero skillata.
> Poi
> > capita sempre che uno vorrebbe fare altro e se lo trova fra le palle
> > comunque: cercare proprio di lavorare in Java e' preposterous.
>
> Su questo non sono del tutto d'accordo. Dipende molto cosa si cerca di
> lavoro, no?


Si, certo. Quello che voglio dire e' che con alcuni linguaggi si puo' fare
la scelta a seguito del mercato che vuoi perseguire. Se vai di C, gran
parte dei lavori che farai saranno in mercato embedded. Se non ti piace (o
scopri che non ti piace), sono cazzi.

Se fai Python hai un po' piu' di margine. Sara' probabilmente web, ma
magari anche automation o desktop o addirittura cose piu' strane.


> Purtroppo non ho davvero una buona idea su quale sia lo
> share per i vari settori dell'informatica (sia in fatturato che numero
> di impiegati), quindi giudico con la mia poca esperienza personale,
> fuori e dentro l'università.
>

Io faccio un discorso un po' diverso. Devi capire cosa vuoi fare, e poi
cercare i lavori. E cerco di tenermi aggiornato su quello che interessa a
me. In questo senso non mi interessa eccessivamente guardare a *quanti*
lavori ci sono in settore che non mi interessa. Non ci vorrei lavorare
comunque.


> Sì, C è embedded, ma OP ha detto che è un ingegnere - non so di che
> tipo - ma così a naso mi sento di dire che embedded è forse una delle
> cose che potrebbero essere più vicine al suo ambito (o comunque
> potrebbe aiutarlo nel caso volesse fare un upgrade (o downgrade...) a
> C++).
>

Vero. E se vuole lavorare in quel mondo e' un'ottima scelta. Questo non lo
sappiamo.


>
> Sì, C++ è specialistico, ma segue un po' le orme del C: credo sia più
> probabile avere accheffare con C++ in ambito ingegneristico che in
> ambito commerciale. Quando ho lavorato con ingegneri (informatici,
> meccanici e aerospaziali) e fisici, usavano quasi tutti C++. Ma,
> forse, ero finito proprio in quel mercato specialistico di cui parli
> :)
>

Mah... C++ salta fuori nei posti piu' impensati. E non e' tutto oro.
Comunque non ho idea di quello che ci hai fatto. Diciamo questo, nelle
realta' "moderne" C++ si usa se e quando serve (anche in modo estremista --
vedi linee guida di Google su C++, guarda quello che bandiscono, e guarda
le motivazioni). Poi ci sono una serie di realta' che lo usano... come
dire, per vari motivi.


> Sì, Java è un mercato-bordello, ma questo significa anche che c'é
> molta richiesta.


Chiaro. Poi c'e' il solito discorso di capire il rapporto fra domanda e
offerta. E ovviamente offerta vuole dire nei campi che ci interessano e con
il profilo che offriamo.

Il fatto che ci sia richiesta, non vuole dire che ci sia richiesta per
qualcuno in determinate condizioni. Non solo: non vuole nemmeno dire che
sia 

Re: [Python] Pycon7

[enrico franchi]

2016-04-23 10:20 GMT+02:00 Andrea D'Amore <and.dam...@gmail.com>:

> 2016-04-23 2:22 GMT+02:00 enrico franchi <enrico.fran...@gmail.com>:
> > Come se Usenet fosse morto... e' semplicemente in animazione sospesa.
> Quando
> > internet soccombera' sotto il peso dei gatti, usenet sara' li, pronto per
> > essere usato di nuovo.
>
> La rivoluzione d'ottobre.
>

Well played.

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

Re: [Python] Pycon7

[enrico franchi]

2016-04-23 2:03 GMT+02:00 m :

marzo dell'anno scorso, usato da me proprio su questa lista: si vede che
> la primavera fa spuntare anche il troll


Hey, sono attivo tutto l'anno.


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

Re: [Python] Pycon7

[enrico franchi]

2016-04-22 20:48 GMT+02:00 Carlos Catucci :

> Era dai vecchi tempi di Usenet che non lo risentivo
>

Come se Usenet fosse morto... e' semplicemente in animazione sospesa.
Quando internet soccombera' sotto il peso dei gatti, usenet sara' li,
pronto per essere usato di nuovo.

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

Re: [Python] Pycon7

[enrico franchi]

2016-04-22 19:32 GMT+02:00 Giorgio Zoppi :

> In barcelona
>

*plonk*


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

Re: [Python] Pycon7

[enrico franchi]

2016-04-21 13:11 GMT+02:00 Fundor333 :

> un workshop sopra Pyston e comparazione con Python and IronPython non
>> sarebbe male.
>
> Favorevole
>

+1




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

Re: [Python] Pycon7

[enrico franchi]

2016-04-21 10:26 GMT+02:00 Simone Federici :

> >> Giorgio Zoppi:
> >>> Sei cosi sicuro di c CIO?
>
> > Simone Federici:
> >> in effetti però parlavo dello zoppo di fatto e non di nome
>
> Giorgio Zoppi:
> > Ok guardo il codice di pyston
>
> Roberto Polli:
>
>> Bravo, vai de Pyston! :DDD
>
>
> non è difficile
>

Grazie a tutti. Che voi non dobbiate mai scrivere PHP.



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

Re: [Python] OT: Imparare un altro linguaggio

[enrico franchi]

2016-04-20 17:43 GMT+01:00 Daniele Tricoli :
>
> Lo consigli rispetto a Scheme? Io ero indeciso tra questi due per iniziare,
> però penso che punterò su Clojure dato che te ne ho sentito parlare più
> volte.
> :)
>

Questione annosa. Scheme e' piu' piccolo (poi scheme 6 non mi ha
impressionato e v7 non lo conosco).
Clojure e' usabile in pratica. Nel senso che non ci sono problemi a pensare
*davvero* di metterci in produzione cose. In questo e' piu' pratico.

Poi ovviamente un "vecchio schemer" ti dira' che Scheme e' meglio (potrebbe
anche avere ragione).

Ma Clojure e' proprio bellino. E' fatto *bene*. Fa il suo mestiere, non
rompe il cazzo in eccesso e lo puoi usare per fare cose "vere". E.g., male
che butta devi fare un wrapper idiomatico per la libreria Java che fa la
cosa che ti serve (se proprio non vuoi usarla direttamente).

Poi chi sia "meglio" lo lascio a chi ha perfino piu' voglia di me di
trollare. Detto fra noi, se un dev qua mi dice, ah, metto su il servizio in
scheme prima cosa che faccio e' fargli fare il palloncino per capire se ci
sta con la testa. Se mi dice clojure gli chiederei brevemente perche' della
scelta e verosimilmente direi ok. Si, io ho una policy tollerante verso
linguaggi non mainstream... principalmente perche' ogni progetto in clojure
e' un progetto che non e' in Java. ;)

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

Re: [Python] L'articolo e' serio, ma titolo e immagin danno una idea precisa

[enrico franchi]

2016-04-20 11:36 GMT+01:00 Carlos Catucci :

> http://culttt.com/2014/07/02/reflection-php/
>
> Scusate, ma non ho resistito. Il fatto di dover poi lavorare coon il poor
> helpless programmers in questi gioorni mi sta pure deprimendo.
>

Meno male che e' serio... articolo su reflection, no? Definizione.

"""
Reflection is where an object is able to introspectively examine itself to
inform you of it’s methods and properties at runtime.
"""

Peccato che quella sia *introspection*. Reflection presuppone *anche* la
capacita' di modificare tutto questo (in qualche modo).



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

Re: [Python] OT: Imparare un altro linguaggio

[enrico franchi]

2016-04-20 13:16 GMT+01:00 Carlo Miron :

> 2016-04-20 12:36 GMT+02:00 Alessandro Re :
>
> > Per quanto mi riguarda la scelta di un prossimo linguaggio... Io
> > voterei per un linguaggio che ti permetta di imparare paradigmi nuovi
> > (specialmente se lo fai per tua passione personale).
>

+1


> > C, te lo consiglio per giocare coi puntatori. Sono una bella cosa da
> > sapere, secondo me, e li trovo anche molto divertenti.
>

+1

Puntatori... gestione della memoria a basso livello dal punto di vista
della macchina.
Nel senso che gestire la memoria a basso livello e' probabilmente piu'
*comodo* in Rust, ma per imparare a pensare a come fa le cose sotto la
macchina, C e' un buon compromesso rispetto ad altro.

Fossero solo i puntatori, tanto vale Go. ;)


> > Scheme/LISP, te li consiglio per la programmazione funzionale pura,
> > che è molto divertente anche quella e può aprirti qualche porta
> > mentale che puoi riutilizzare in altri linguaggi moderni (java,
> > python...)
>

Si alla programmazione funzionale "pura". Lisp lo definirei tutto meno che
"funzionale puro". Cioe', puoi limitarti ad un sottoinsieme "puro" di Lisp,
ma Lisp, per scelta, e' realmente multi-paradigma. Scheme pure, ma e' un
pochetto piu' piccolo e un pochetto piu' "ordinato". Per dire... il loop di
Lisp e' pesantemente imperativo (potentissimo e ci vanno 4 anni solo a
capire tutto quello che puo' fare).

Fra i "lisp like" per assurdo uno dei piu' puri e interessanti e' Clojure.
Molto molto bellino.

Fra i "puri"... beh, SML, Haskell... ma puo' piacere e non piacere. Clojure
e' un buon compromesso a mio avviso. Ti da il feel delle S-expression, ti
da delle macro che non sono limitate come quelle di Scheme, ma semplifica i
casi piu' spinosi di quelle di Lisp. Funzionale. Stateless (se non quando e
come vuoi tu, in modo molto ordinato).


> > Erlang/go, te li consiglio se vuoi divertirti con la concorrenza e il
> > parallelismo. Ho trovato molto belli i paradigmi che usano, e sebbene
> > non usi erlang da un bel po', ancora adoro il pattern matching che
> > usa.
>

Si. Go e' anche un ottima scelta per capire quali siano le parti sane della
programmazione ad oggetti. ;)


> > Poi oh, vedi te cosa vuoi fartene :) Se devi cercarti un lavoro...
> > Andrei su C/C++/Java.
>

Io direi di no. C e' soprattutto embedded. C++ si trova da lavorare ma e'
molto specialistico. Java e' un mercato agguerrito. I posti di lavoro
interessanti li pigliano la gente *davvero* sveglia o davvero skillata. Poi
capita sempre che uno vorrebbe fare altro e se lo trova fra le palle
comunque: cercare proprio di lavorare in Java e' preposterous.


>
> Nick Coghlan qualche giorno fa su [Python-ideas] consigliava:
>
> | It's also the case that any developer with only one language currently
> | in their toolbox (even when that language is Python) is a developer
> | with lots of learning opportunities ahead of them:
> | <
> http://www.curiousefficiency.org/posts/2015/10/languages-to-improve-your-python.html
> >
>


Interessante.


>
> ㎝
>
> --
> |:**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
>



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

Re: [Python] GO e le GUI grafiche.

[enrico franchi]

2016-04-14 12:46 GMT+01:00 Gabriele Battaglia :

A coloro che conoscono le basi del linguaggio chiedo, come è, costruire le
> interfacce grafiche, in Windows, usando GO?


Mi sembra cercare guai gratuitamente. Windows tende ad essere un cittadino
di seconda classe (per Go e per tanti altri). Non solo... le interfacce
grafiche non sono certo una priorita' per Go.

Parliamoci chiaro... se il tuo obiettivo e' fare UI per Windows, il mondo
Microsoft potrebbe avere svariati vantaggi rispetto ai concorrenti, in
termini di semplicita' di un botto di cose.


> Il livello di complessità è pari a quello in Python?


No, e' significativamente minore sotto molti punti di vista. Ma devi sapere
quello che fai.
E ovviamente in Python c'e' chi "riduce" la complessita' rinunciando ad
alcune delle parti piu' interessanti di Python. Per cui, sebbene di per se
Go sia un linguaggio *molto* meno complesso di Python ("tutto python"), se
si rinuncia a leggere e capire il codice scritto da altri (o rinunciare a
leggere molto del codice scritto da altri), e si rinunciano a molte delle
cose che rendono Python tutto sommato un linguaggio interessante... beh,
l'omogenizzato di Python che rimane e' probabilmente piu' semplice
dell'intero linguaggio Go. Non lo trovo particolarmente interessante da
scrivere, d'altra parte.

Applicare un processo simile a Go potrebbe essere un problema, perche' Go
e' veramente minimale. Non mi viene in mente molto che si puo' togliere
senza compromettere significativamente la capacita' di risolvere problemi.


> Quali e quanto ampia la scelta di librerie per gli oggetti grafici?


Diciamo che nel 2016 il focus dell'IT non e' certo le interfacce grafiche.
Non lo e' da forse 15 anni.
Specialmente nella community Go, le GUI desktop sono piu' una novelty che
qualcosa di realmente utile (si ok, puoi fare una GUI desktop in Go...).

Quindi direi... qualcosa trovi. Ma e' piu' interessante per qualcuno il cui
focus sia "fare tutto in Go" (per vari motivi) rispetto che per qualcuno
che vuole "fare interfacce grafiche su Windows" (senza avere nessun vincolo
ad usare Go).


> In termini di complessità e concisione di linguaggio, quale fra Python e
> GO è più immediatamente o facilmente comprensibile?
>

Per chi?



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

Re: [Python] OT: Imparare un altro linguaggio

[enrico franchi]

2016-04-14 11:03 GMT+01:00 greenkey loman :

Insomma, se si vuole fare una scelta guidata dal CV (Resumè Driven
> Development) forse è il caso di provare con Java.
>

Dati parziali, con cui ottieni un'impressione parziale. Il numero di job
posting e' rilevante "astratto" solo se sei completamente average su tutto
e non hai alcuna preferenza. Se hai preferenze su quello che vuoi fare,
dovresti vedere, al limite, il numero di job posting per linguaggio nella
tua area di preferenza. Non solo: il linguaggio da solo potrebbe non
bastare per avere accesso a quel lavoro: tanto per tenerla semplice, se sei
"semplicemente" un programmatore Java ma non sai una fava di EE, non
riuscirai facilmente solo per il fatto di sapere Java a prendere un lavoro
centrato su tutto il mondo Java EE. O piu' semplicemente capire a quanti
ambiti lavorativi dove e' piacevole lavorare si ha accesso con un certo
linguaggio/tecnologia. Poi ci sono discorsi tipo: voglio/non voglio andare
in una startup/big company/banca/pa/pmi. Non a tutti piacciono le stesse
cose.

E poi devi capire il tuo livello di seniority. E' inutile contare una
posizione da senior se sei junior, e se sei senior una posizione molto
junior non ti interessa molto. Allo stesso modo e' interessante cercare di
capire quale sarebbe lo stipendio che potresti prendere una volta appreso
un linguaggio abbastanza da lavorarci.

Piu' ci sono tutta una serie di categorie di lavori (fra cui si trovano
spesso le posizioni piu' interessanti) che *non* sono categorizzate per
linguaggio. Cerchi un software engineer bravo.. tanto nessuno sa tutto e ti
interessa qualcuno che riesca ad apprendere agilmente quello che serve.

Detto questo, oggettivamente il mondo lavorativo Java e' sufficientemente
ampio da esserci roba un po' per tutti gli "argomenti", ci sono realta'
dove e' piacevole lavorare, di tutte le dimensioni e ambiti, etc etc etc.


>
> In Italia poi siamo più indietro del resto del mondo (USA, UK...), ho
> l'impressione che Java andrà avanti ancora per molto tempo.
>

Ma anche nel resto del mondo, eh. D'altra parte Java non e' ne una
tecnologia bleeding edge, con tutto il rischio e il vantaggio economico
associati e non e' nemmeno legacy (con tutti i vantaggi--specie
monetari--/svantaggi associati).



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

Re: [Python] Python 8

[enrico franchi]

2016-04-01 16:59 GMT+01:00 :

> L'account leona...@deasistemi.com non è più attivo.
>

Ma persiste nello scassare la minchia.


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

Re: [Python] LOL

[enrico franchi]

2016-03-22 22:13 GMT+00:00 Carlos Catucci :

> e tronchiamola. Piu 'insistete a parlarne e meno verra'0 troncata.
>

Vero.


> Vome uktima cosa voglio far notare che la cosa era in se goliardica, e ho
> dato alla frase una interpretazione diversa da quella che molti anno dato
> qui. Non era intesa come cosa omofoba (non sono omofobo, come non sono
> rzzista, ne fanatico). Chiedo scusa se involontariamente ho urtato
> qualcuno, ma ribadisco che la malizia e' piu' spesso nella testa di chi
> attribuisce ad una battuta un significato razzista/omofobo o quant'altro
> che nelle intenzioni di chi la ha scritta/proposta
>

Guarda, io personalmente non sono offeso. In quanto Italiano all'estero
sono oggetto di continua scherzosa goliardia (ovvero, sono chiaramente
*mafioso*, devo avere sicuramente esperienza di *corruzione*, probabilmente
sono corrotto a mia volta, etc etc etc -- si bravo, tutti reati e pure
pesanti --). Se invece che essere semplicemente Italiano appartenessi a una
qualche "minoranza con un forte ufficio PR", tutto questo cesserebbe di
essere scherzosa goliardia, ci sarebbero levate di scudi e la gente
finirebbe messa alla gogna. Pero' sono solo italiano e piuttosto mainstream.

E si, la mia opinione personale e' che "chissene frega". La battuta e'
vecchiotta, e' in giro da tanto. Non la trovo particolarmente divertente
proprio perche' l'ho sentita tante volte. E' fuori dalle "nuove linee di
condotta"? Si. Indubbiamente. Che fare... cerco di rispettarle in quanto
decise dalla community. Un bel giorno, e' certo, non mi stara' piu' bene
rispettarle e mi limitero' a discutere con persone che hanno sensibilita'
compatibile con la mia, con un concetto di umorismo compatibile con il mio,
etc etc etc. Finiro' a parlare da solo? Forse. Ma fra parlare da solo e
avere paura di parlare, preferisco parlare da solo.


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

Re: [Python] LOL

[enrico franchi]

2016-03-21 19:05 GMT+00:00 Giovanni Porcari :

> Dimentichi la cosa peggiore… si parlava anche di Java ;)
>

you might have a point...




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

Re: [Python] LOL

[enrico franchi]

2016-03-21 17:42 GMT+00:00 enrico franchi <enrico.fran...@gmail.com>:

> Tipicamente se sei omofobo (o hai visioni ristrette sul sesso)
> probabilmente e' giusto: e' omofobia. Se non hai visioni ristrette sul
> sesso...


Rileggendomi sembra che stia asserendo che hai visioni ristrette. Non e'
mia intenzione.
Il succo e'... il concetto e' molto piu' ampio, coinvolge coppie di ogni
tipo ed e' una scelta dell'ascoltatore collegare la faccenda ad
"omosessualita'". Ad ognuno fare saltare in mente per prima cosa una cosa
diversa che dipende dall'individuo.

Resta il fatto che non e' appropriato.


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

Re: [Python] LOL

[enrico franchi]

2016-03-21 9:23 GMT+00:00 Nicola Larosa :

Implicare che il sesso anale non è buono e che non è adatto a tutti i
> generi non lo chiamerei né "parlarne" né "prendersi in giro
> bonariamente". Lo chiamerei col suo nome: omofobia.
>

Scusa ma la questione secondo me e' completamente diversa. Parlare di sesso
anale (o di sesso in altra maniera) e' verosimilmente contrario alle varie
policy code of conduct etc etc etc. Ma perche' e' parlare di sesso.

Il fatto che parlare di sesso anale (o parlarne in modo derogatorio) sia
legato all'omofobia e' piu' complicato. Tipicamente se sei omofobo (o hai
visioni ristrette sul sesso) probabilmente e' giusto: e' omofobia. Se non
hai visioni ristrette sul sesso... il sesso anale puo' essere praticato da
due partner adulti consenzienti di ogni sesso attribuito alla nascita,
identita' di genere e orientamento sessuale. Essenzialmente l'unico
requisito e' che sia presente l'orifizio suddetto che e' di serie su quasi
tutti gli esseri umani. Grosso modo funziona con tutte le combinazioni.

Il punto forte (per cui non proseguirei la discussione) e' che parlare di
*sesso* probabilmente non e' appropriato. E quella battuta non e'
appropriata secondo le varie norme di condotta.



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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-18 10:28 GMT+00:00 Carlos Catucci :

> Tutto e' relativo, dipende dal contesto.
>

Yep.


> Io per esempio per garantire di poter lavorare anche se la ruspa dei
> lavori in corso trancia i cavi dell'adsl (ci e' successo realmente a
> Modena) un rapsino con un disco in replica che puo' fungere da macchina di
> backup locale lo propongo. Poi dipende da cosa fa il servizio/applicazione.
> Se devo solo consultare ogni tanto non da problemi, ma se ho tutto li sopra
> ecco che il sistema di backup locale diventa vitale.
>

Breaking news... da qualche mese e' disponibile una nuova cosa chiamata
"cloud computing", che vuole dire che in pratica ti scegli il modello di
ridondanza/availability che vuoi e fine della fiera. Vuoi piu' availably
zones? Puoi. Pensi che tutto sommato devi proteggerti da un evento
catastrofico, che so... in us-east-1? bene... prendi qualcosa anche in
us-east-2. Pensi che tutta l'america possa venire invasa dagli alieni (ci
sono le foto! [0]), prendi qualcosa anche che so... in Australia. I canguri
terranno lontani gli alieni. Etc etc etc. ;)

Poi le ruspe continueranno a tranciare i cavi. Pero' smette di essere un
problema tuo...


---
[0]
http://vignette3.wikia.nocookie.net/aliens/images/b/b2/Alien_Independence_Day.png/revision/latest?cb=20110124141918



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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-18 10:58 GMT+00:00 Gollum1 :

>
>
> lasciamo perdere va... sono da mesi oramai che chiedo di replicare
> localmente un server di autenticazione, che ora è solo a Roma...
>
> in un paio di occasioni c'é stato un problema sulle linee di
> comunicazione, e ci siamo trovati con la produzione ferma, solo perché
> gli utenti (montatori) non potevano loggarsi sulle macchine di
> montaggio... (una delle due volte, si era spenta tutta la farm in cui
> risiedono i loro server di autenticazione, un disastro).
>
> ma ingegneria non ci sente... stupidi...
>
>
Unipr, l'anno scorso... storia breve, c'era un UPS vecchiotto che stava
schiattando. Dovevano fare lavori elettrici.
Fanno i lavori elettrici. L'UPS era vecchio ed e' schiattato. Doveva essere
ridondato ma non lo era.
Va giu' un po' di roba... nulla di importante, se non, precisamente, il
server di autenticazione. Bene... non ridondato. Meglio. Avevo detto storia
breve? Beh, in pratica *tutto* (email inclusa) ha smesso di funzionare per
10 giorni... fra cui l'iscrizione agli esami.


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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-15 18:22 GMT+00:00 Carlos Catucci :

> Questione di scala Enrico.


A me verrebbe dire anche questione di business, piuttosto. O se vuoi, del
tipo di business e del modello di deploy che hai.

Per esempio se fai sw "boxed" i rilasci sono costosissimi e vuoi certamente
dell'infrastruttura massiccia di QA. D'altra parte per la maggior parte dei
sw l'utente si aspetta che ci siano dei bachi. Insomma, Word (o chi per
lui) ogni tanto crasha. Lo sappiamo tutti e continuiamo ad usarlo (magari
usiamo il "chi per lui", che a sua volta ogni tanto va giu'). Pero' grosso
modo e' su... il motivo e' che di fatto l'infrastruttura e' interamente in
mano all'utente. Che d'altra parte vuole dire che determinati tipi di
testing diventano molto piu' complicati. Il caso "pessimo" e' quello dei
giochi che magari hanno bachi nei motori grafici che sono triggerati solo
da certe combinazioni di un certo modello di scheda video con una certa
versione dei driver su una certa versione di un certo sistema operativo.

Se c'e' un baco, si considera ok aspettare qualche mese per avere una minor
version che lo aggiusta. Inoltre, se si introduce un baco, basta dare un
buon modo all'utente di usare la vecchia versione e probabilmente gli si da
solo un fastidio marginale. Non solo... certi utenti si aspettano che la
nuova versione abbia bachi e prima di "adottarla" la testano. Pochi, eh...
ma spesso quelli per cui e' veramente critico lo fanno.

Il modello dei servizi web e' opposto. Ci si aspettano rilasci brevi. Ci si
aspetta che il software sia sempre su. I bachi sono una cosa statistica:
ovvero sappiamo che per qualche utente ci saranno dei problemi, ma fintanto
che il singolo utente non ha problemi troppo spesso si puo' tollerare. Poi
ci sono un mucchio di cose che sappiamo che andranno storte... quindi via
di retry. Che so... se faccio una chiamata ad un servizio, puo' andare male
anche solo per questioni di rete o del momento in cui succede. Ma magari il
servizio di per se e' su e non c'e' davvero un "baco" nel codice. Riprovo
tutto e vado. Magari l'utente stesso e' disposto di tanto in tanto a
ricaricare la pagina per aggiustare una situazione.

E anche qui... e' diverso fare un servizio che "vendi" ad un'azienda il cui
business ne dipende. Se "vendo" un servizio di billing per ecommerce e io
sono giu', i miei clienti non possono fatturare. Non saranno tolleranti. Se
fallisco una transazione su 100, non saranno contenti. Se a mia volta il
mio servizio e' un ecommerce, gli stessi problemi sopra descritti possono
volere dire meno vendite e meno soldi. Downtime vuole dire perdite
monetarie quantificabili immediatamente. Non solo... non posso nemmeno
facilmente testare il mio codice in produzione (ovvero, iniziare a
deployare timidamente e sperare che funzioni tutto). Viceversa se sto
facendo un servizio per condividere una bacheca di puttanate con i miei
amici, posso: 1) fallire di tanto in tanto, inoltre, siccome molti fanno
sta roba dal cellulare, potrebbero addirittura pensare che non sono io a
fallire, ma che e' la connessione che e' singhiozzante; 2) testare feature
su pochi clienti alla volta... posso anche convincerli di essere fortunati
a starmi facendo da beta tester a gratis. Un celebre servizio di
microblogging aveva problemi immensi di availability eppure si e' comunque
espanso.

Comunque a prescindere da quale situazione sia, in generale "non so chi
sono i miei clienti". Ovvero sono tanti, continuano ad entrare e,
potenzialmente, ad uscire. Mi possono abbandonare probabilmente con un
costo limitato. La mia reputazione e' una cosa globale, invece: qualche
post su twitter di persone chiave puo' crearmi grossissimi problemi. Tutti
sanno chi sono (o per lo meno, tutti quelli che sono interessati al tipo di
servizio che sto vendendo/proponendo).

Se quello che fai e' invece offrire soluzioni "individuali" per clienti, e'
un mercato ancora diverso. C'e' un rapporto piu' stretto. I tempi in
qualche modo li da il cliente (mentre se faccio servizi web i tempi li da
"il mercato" -- se siamo i secondi a rilasciare questa feature abbiamo
perso la battaglia -- oppure essere quasi interno -- rilascio questa
feature quando e' pronta, o ancora, rilascio tutte le settimane, ma includo
nel rilascio solo quello che e' pronto). E poi dipendera' di volta in volta
come vengono fatti deployment, aggiornamenti, new release; se le macchine
sono mie o del cliente, quanta gestione ho sulle macchine, etc etc etc.


Questo solo per dire che siccome i modelli di business sono davvero
diversi, non e' affatto detto che una strategia completamente accettabile
in una situazione sia completamente suicida in un'altra.


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

Re: [Python] attributi astratti?

[enrico franchi]

2016-03-15 17:15 GMT+00:00 Marco Santamaria :


> In realtà da Python 3.3 è deprecato in favore dell'uso combinato di
> @property e @abstractmethod.
>

Vero. Comunque il concetto e' quello.


> Il guaio di questo approccio è che le classi derivate devono implementare
> un metodo decorato con @property e non basta definire una proprietà
> (giustamente non attributo, che è più generale) come con @abstractmethod
>

Esatto. Solo che non e' banale fare veramente un "abstractattribute".



> Poi mi è venuta in mente anche una quarta possibilità: chiamare hasattr
> nel metodo __new__ della classe astratta, cosa che segnala l'eccezione un
> po' prima che se chiamato in __init__
>

Farlo in __new__ e' marginalmente meglio che farlo in __init__ per vari
motivi (non tanto il fatto che sia segnalata "un po' prima" -- dal punto di
vista dell'utente l'eccezione "esce" nello stesso punto). E non e'
esattamente chiaro se sia meglio controllare con hasattr (o equivalente)
sull'oggetto oppure guardare i parametri di input.

Quello che vorrei fosse chiaro e' che in questo universo il tuo problema e'
che dipendi in modo marcato da cose fuori dal tuo controllo. Cioe', il
motivo per cui ti stai sbattendo per questo "abstract attribute" e' che
vuoi di fatto dare sta libreria in mano a terze parti (potenzialmente anche
interni) e vuoi evitare che il contratto del tuo codice non sia mantenuto
(e se non lo e', segnalarlo in modo opportuno).

Solo che Python ti consente di fare tantissime cose (anche molto sensate) e
che il *come* le fai puo' vuole dire che il tuo controllo funziona o
meglio. Per dire... cosa succede se uno ha delle namedtuples nella
gerarchia da qualche parte? Mica banale...



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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-10 14:21 GMT+00:00 Giovanni Porcari :

>
> Si. Tutto vero.  Tutto sacrosanto. Tutto giusto.
>
> Però come dicevo in un'altra mail è un problema di risorse che puoi avere
> e non avere
> e le compatibilità economiche non sono meno importanti di quelle tecniche.
>

Si, appunto. Per determinati business (che so, se fai servizi web based) il
costo di un baco in produzione sufficientemente grave puo' anche nella
peggiore delle ipotesi farti chiudere baracca. Se i clienti perdono fiducia
nel tuo business, semplicemente non hai piu' clienti (per lo meno, nel
lungo termine). Se il business fa billing sulla base delle transazioni dei
clienti, downtime vuole dire potenzialmente milioni di dollari di mancate
entrate. In ogni caso probabilmente hai delle SLA che devi rispettare, e se
non le rispetti devi sbatterti non poco per scusarti (e generalmente tutto
questo coinvolge ancora una volta mancate entrate)

Certo, se vendi software "boxed" sei in un mondo completamente diverso.
Come e' diverso se vendi soluzioni custom per clienti singoli, e magari ti
va anche bene. Eh, scusa, eravamo giu' per un paio di ore, ma dai, non ti
preoccupare. In altri casi questo e' un pochetto piu' complicato.

Non posso parlare per altri ma solo per me. Lavoro in questo ambito da più
> di 40 anni
> e non ho mai infilato in produzione dei bachi che non fossero 'cosmetici'.
>

Eh... che dire. Bravi. La mia esperienza, sebbene molto piu' breve, e'
tutta diversa.

Diciamo cosi'... l'esperienza (breve finche' vuoi) mi insegna a diffidare
molto di questo tipo di affermazioni.

Nel mio mondo, la parola chiave e' "build to fail". I sistemi falliranno.
Il trucco e' essere sufficientemente ridondanti. E il costo ingegnere di
scrivere un test e' assolutamente *nullo* rispetto al costo di tenere in
piedi la baracca (che a sua volta e' completamente trascurabile rispetto al
costo di fallire davvero).

Che poi questo dipenda da fortuna, capacità, senso di responsabilità o
> attenzione non lo so.
>

La fortuna non perdura in eterno, il senso di responsabilita' non aiuta
(ovvero, l'incoscienza chiaramente rema contro, ma non direi che e' un
problema di "senso di responsabilita'"). Attenzione? Forse. Ma vuole anche
dire che il business ha tempi molto lenti (o se vuoi "umani"). Ma
soprattutto, non e' una garanzia. Perche' sei attento fino alla volta in
cui sei disattento.

Se vai a vedere come gestiscono le cose quelli che *non* possono
permettersi bachi *per nulla* (sarebbe piuttosto sgradevole un 404 con
l'omino dei lavori in corso sul monitor del 747 che sta precipitando con
500 persone a bordo -- sorry, we are working for you: ATC will be online in
a couple of hours, please consult your onboard spiritual advisor for your
last prayers). Beh... vedrai che non ti parlano di "attenzione" e "senso di
responsabilita'". Semmai hanno svariati team di QA che fanno test manuali,
automatici, randomizzati e pagano licenze piuttosto costose per tool che
fanno analisi statica e dimostrano l'assenza di determinati bachi in
determinate parti del codice. E a volte tutto questo si rompe e nonostante
tutto si va Arianne 5.

Ora tutto questo ha un costo immenso. Per lo meno vuole dire un ciclo di
sviluppo cosi' lungo che nel mio mondo saremmo tutti fuori dal business. E
quindi via di compromessi. Oltretutto un moderno sistema software e'
*molto* piu' complicato della maggior parte dei sistemi mission critical di
quel tipo (principalmente perche' il costo di non introdurre una feature
puo' essere molto piu' alto del costo del rischio di un downtime).

Forse il rovescio della medaglia è che se ti convinci che i test comunque
> ti parano il culo
> tendi a lavorare con il medesimo.
>

"True man do not write bugs". No. La gente scrive i test quando lavora
bene. Se non scrive i test, dal mio punto di vista, sta lavorando con il
culo. Ci sono talmente tante buone ragioni per scrivere i test... e quale
ragione per non scriverli? Risparmio tempo? In generale si dimostra che non
e' manco vero che si risparmia tempo sul lungo termine. Poi certo, se uno
se la gioca tutta sul fatto che "va in bancarotta sul debito tecnico" ok...
ma non e' un gran piano nel caso generale.

Un po' come l'acrobata che cammina sul filo senza la rete sotto: o sta
> attento o è un uomo morto.
>

Ecco... ma noi siamo acrobati che lavorano troppe ore al giorno su un filo
invisibile con illuminazione a lume di candela fatta dal pubblico
sottostante. E il filo non e' dritto ma va un po' di qua e un po' di la. E
un orso ubriaco con la faccia di Bruce Campbell ci sta inseguendo con una
motosega al posto della zampa destra.

Io non dico che avere un'ottima copertura dei test sia sbagliato anzi, è
> una cosa meravigliosa.
> Dico solo che io, purtroppo, non me la posso permettere :)
>

E io non conosco il tuo business, per cui non posso e non voglio commentare
oltre. I tuoi clienti sono contenti, restano, e ne continuano ad arrivare
di nuovi? Allora vuole dire che stai facendo 

Re: [Python] attributi astratti?

[enrico franchi]

2016-03-11 16:13 GMT+00:00 Marco Santamaria :

sto lavorando ad un piccolo framework nel quale mi sento autorizzato ad
> usare il modulo abc per creare delle classi astratte/interfacce per
> permetterne l'estensione.
>

Ok. Va bene.


>
> Mi sono trovato spesso a dover assicurare la presenza di un attributo
> nelle classi derivate da una classe astratta, senza avere la possibilità di
> fornire un valore di default ragionevole.
>

O a me non e' chiaro quale sia il tuo problema concreto, oppure tu non hai
guardato la doc per abstractproperty.

https://docs.python.org/2/library/abc.html#abc.abstractproperty

E' una cosa sottilmente diversa da quello che vuoi fare tu... che vuole
dire che potrebbe essere perfetto (o essere perfetto una volta che ti
orienti nella sua direzione) oppure totalmente inadatto. Questo lo puoi
sapere solo tu.

Personalmente lo considererei perche' si muove nello stesso spazio di
problemi che descrivi. Ovviamente non funziona *esattamente* come quello
che descrivi. In pratica lui ti assicura la presenza di una *property* che
fa quello che vuoi, mentre un attributo e' un concetto un pochetto piu'
generale.

In [1]: import abc

In [2]: class B(object):
   ...: __metaclass__ = abc.ABCMeta
   ...: @abc.abstractproperty
   ...: def foo(self): pass
   ...:

In [3]: class A(B): pass

In [4]: A()
---
TypeError Traceback (most recent call last)
 in ()
> 1 A()

TypeError: Can't instantiate abstract class A with abstract methods foo

In [5]: A(foo='bar')
---
TypeError Traceback (most recent call last)
 in ()
> 1 A(foo='bar')

TypeError: object() takes no parameters

In [6]: class AOK(B):
   ...: @property
   ...: def foo(self): return 42
   ...:

In [7]: AOK().foo
Out[7]: 42

In [8]: class ABad(B):
   ...: def __init__(self, foo):
   ...: self.foo = foo
   ...:

In [9]: ABad(foo=42).foo
---
TypeError Traceback (most recent call last)
 in ()
> 1 ABad(foo=42).foo

TypeError: Can't instantiate abstract class ABad with abstract methods foo


> Data la natura dinamica di Python questo può essere fatto in vari modi, ma
> mi chiedo quale sia quello più 'idiomatico' in Python 3.4, facendo in modo
> che venga sollevata il prima possibile un'eccezione chiara se
> quell'attributo non viene definito.
>
> Al momento mi sono venute in mente tre soluzioni:
>
>1. controllare con hasattr la presenza dell'attributo nel metodo
>__init__ della classe astratta
>2. definire nella classe astratta una proprietà (decorata con
>@property) che solleva un'eccezione NotImplementedError
>3. definire nella classe astratta un metodo astratto (decorato con
>@abstractmethod) con lo stesso nome dell'attributo
>
> Sto usando la 3. quando possibile perché solleva un'eccezione prima delle
> altre, ma non mi piace molto l'idea di richiedere un metodo quando voglio
> un attributo.
>

Ok. Se stai usando la 3, passare ad abstractproperty ti avvicina un po' a
quello che vuoi. La 2 e' una versione fatta con lo scotch di
abstractproperty (o meglio, sta ad abstractproperty come fare un metodo che
ti tira not implemented sta ad abstractmethod: specificamente la differenza
e' quando ottieni l'errore; abstract* ti da un errore se quando istanzi
l'oggetto un determinato ente non e' nell'mro dell'oggetto, viceversa
tirare sulla chiamata te lo segnala appunto se e solo se lo chiami... non
entro nel merito del quando preferisco uno o l'altro perche' e' complicato).

hasattr funzionicchia, ma hai un sacco di edge case fastidiosi. Per esempio
ti rende molto vulnerabile all'ordine di risoluzione dei metodi (mro) e al
fatto che qualche derivata *non* chiami l'__init__ che vorresti tu. Secondo
me e'facile impiccarsi con una soluzione che apparentemente funziona, ma in
pratica lascia fuori sufficienti casi da scoprire in produzione che
effettivamente non funzionava.

abstractproperty ha il vantaggio che a fronte di essere marginalmente piu'
scomodo da scrivere e' molto chiaro nell'intento ed e' relativamente
improbabile scavalcarlo "per errore".



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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-10 1:34 GMT+00:00 Marco Beri :

> 2016-03-09 23:53 GMT+01:00 Giovanni Porcari 
> :
>
>> Comunque i bachi più insidiosi, purtroppo non li scovi con i test.
>
>
Giovanni, e' una posizione complicata e rischiosa. Cioe', oggettivamente,
siamo tutti adulti (chi piu' chi meno) e si puo' ammettere che
effettivamente ci sono bachi che fai fatica a scovare con i test. Possiamo
anche dire che meno il codice e' testabile e piu' e' facile che suddetti
bachi esistano.

Pero' mettere "in avanti" questa affermazione porta problemi. E' *diverso*
avere il baco, vedere il servizio crollare come un castello di carte, fare
root cause analysis, trovare di conseguenza il problema e a quel punto,
quando ci si va a chiedere cosa si sarebbe potuto fare per evitarlo (ovvero
cosa si fara' perche' non si ripresenti) constatare che si, quel baco era
talmente complicato da scovare con i test che di fatto "non si sarebbe
potuto fare di meglio" e che l'unica cosa che si puo' fare e' mettere a sto
punto dei regression test. A me verrebbe pure da aggiungere che
bisognerebbe riflettere sul perche' quel codice contiene bachi insidiosi
che non acchiappi con i test (nota, non sto parlando di genro, sono in
astratto).

Ma mettere *a priori* l'affermazione "comunque i bachi piu' insidiosi non
li scopri con i test" e' un po' un blanket statement che si legge come: i
test non servono davvero troppo, quindi inutile spendere il costo di
scriverli.


> Non è che i test ti fanno scoprire i bachi.
>

Si, i test ti fanno anche scoprire i bachi. Fare test come si deve *prima*
di andare in produzione tipicamente acchiappa un mucchio di bachi. Fare
integration testing ne acchiappa altri. Ehi... perfino fare load testing
acchiappa "bachi" (ok, tecnicamente non sono bachi, ma sono sempre cose che
fanno svegliare la notte e fanno incazzare gli utenti.


> I test ti garantiscono le non regressioni (e già questo li rende
> irrinunciabili).
>

+1


> Poi, quando scovi un baco, la prima cosa da fare è scrivere un test che lo
> evidenzi. Solo dopo lo correggi (e te ne accorgi quando passa il test che
> lo evidenziava).
>

+1


> Così è più faticoso che fixare subito il baco? Certo. Ma a tendere è più
> conveniente? Più certo ancora.
>

Anche perche' se no che faccio... prendo il codice che *credo* fixi il baco
e lo metto in produzione? E poi scopro che non fixa un accidenti? O che
magari non ho capito il baco? E che magari il fix in realta' oltre fixare
un baco introduce un problema? No TY.



> Dici che c'è del  codice non si può testare?
>
Chiedi a Valentino, lui ti direbbe che non esiste codice siffatto :-)
>

No no... esiste: si chiama codice scritto ammerda. E' una proprieta'
assolutamente cross-platform e cross-linguaggio.
Aggiungo... secondo me c'e' piu' codice scritto ammerda che codice scritto
ammodo.


> C'è chi sostiene che un bug è in realtà un test non scritto.
>

Non troppo lontana dalla realta'.


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

Re: [Python] R: Re: R: Salve a tutti, sono nuovo.

[enrico franchi]

>
>
> 2016-03-03 18:31 GMT+01:00 enrico franchi <enrico.fran...@gmail.com>:
>
>> Per il resto, capiscimi... mi hanno spedito in yankeeland, mi connetto,
>> vedo quoting inumano dappertutto... che devo fare?
>
>
> Una alternativa e' fare Bowling a Columbine oppure divbenater un emulo del
> BOFH
>

Tenendo conto la mia avversione per le armi da fuoco e ogni tipo di azione
indiscriminata, e' chiaro quale sia il mio destino.

Per inciso, questa e' diventata la mia bucket list:
https://www.reddit.com/r/sysadmin/comments/2gt7x5/just_sysadmin_things_for_which_ive_been

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

Re: [Python] MySQLdb connect non aggiorna i dati sui client

[enrico franchi]

2016-03-07 15:56 GMT-08:00 Enrico Bianchi :

> cosa potrebbe essere?
>>
> Di tutto, anche se propenderei ad un problema lato codice (ok che MySQL fa
> cagare, ma non fino a questo punto)


+1; da cui suggerivo che invece di smacchinare con la conf di MySQL si
facesse un briciolo di root cause analysis.


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

Re: [Python] MySQLdb connect non aggiorna i dati sui client

[enrico franchi]

2016-03-07 11:42 GMT-08:00 Roberto Polli <robipo...@gmail.com>:

> Il 7 marzo 2016 18:53, enrico franchi <enrico.fran...@gmail.com> ha
> scritto:
> >> MySQL è un db più general purpose ;) puoi decidere il pH.
> > ???
> pH = grado di ACID-ità ;D
>
> > Gli standard ti dicono *cosa* devi supportare, non ti dicono quanto sia
> una
> > buona idea usare una determinata feature per risolvere un determinato
> > problema.
> Non ho capito: MySQL ti *permette* di settare l'isolation level.
> Questo non vuol dire che sia giusto farlo. Ma neanche che sia
> sbagliato darti la possibilità di farlo.
>

Corretto entrambe. Io mi limito a dire che secondo me non e' la soluzione
al problema di OP.
E che, specificamente, secondo me c'e' qualcosa di veramente e
profondamente sbagliato nel modo in cui il codice di OP parla con MySQL.

In particolare, il suo problema apparentemente e' che gli altri client non
leggono dati *committati*. Lui in questo modo invece sta aprendo il mondo a
leggere sia i dati committati sia quelli non committati. A me di casi in
cui veramente si vuole questa cosa ne vengono in mente alcuni, ma sono
tutti relativamente poco generali. Il che mi fa pensare che probabilmente
non e' quello che vuole.

Messo insieme a "mi hanno suggerito questa soluzione" (che si legge
drammaticamente come "cosi' sembra funzionare ma non so perche'") mi fa
pensare che per ora OP abbia spostato la canna del fucile dal piede, senza
accorgersi che era un fucile Michael Angelo Style (
https://s-media-cache-ak0.pinimg.com/236x/87/07/d9/8707d9482727e661c992471e22ad5ce5.jpg)
e che nel contempo si e' puntato due altre canne, una per piede e una da
un'altra parte. Ora, io sto suggerendo di rendersi conto di questa cosa
prima di provare a premere il grilletto: la polemica mi interessa poco.


> > Variazioni della frase: "con la ${v2} stanno migliorando molto. Il
> problema
> > e' il numero di ${v1} ancora in giro... " le sento da tipo 15 anni.
> Parafraso ;) MySQL 5.5 è uscito nel 2009. Se poi ancora andiamo in
> giro con la 5.1 va bene tutto :DDD
>
> Quindi:
>
>   - ok se mi dici che MySQL fa' schifo perché sulle tabelle
> hash-partizionate tutti i vincoli relazionali devono includere la
> chiave;
>   - ko se parli di myisam che non è l'engine di default da circa 7 anni.


Io non ho detto che myisam sia l'engine di default. MySQL e' un progetto
del 1995. Il che prendendo buona la tua data di 7 anni fa (non ho davvero
voglia di controllare), vuole dire che per *14* anni hanno pensato che
fosse una buona idea shippare un db relazionale con come default con un
coso che in pratica non supporta il modello relazionale. Da cui il mio
commento che sta roba di correttezza, ACID, foreign keys non sono
esattamente il primo concern in quella community.

La mia impressione e' che nella community MySQL (non nel prodotto MySQL) un
sacco di cose scontatissime altrove sembrano rocket science.

Poi si puo' parlare a lungo del prodotto in se, figuriamoci.

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

Re: [Python] MySQLdb connect non aggiorna i dati sui client

[enrico franchi]

2016-03-04 2:42 GMT-08:00 Roberto Polli <robipo...@gmail.com>:

> Ciao a tutti,
>
> Il 3 marzo 2016 18:18, enrico franchi <enrico.fran...@gmail.com> ha
> scritto:
> > Verrebbe anche da dire che la community di MySQL e' relativamente poco
> > sensibile al fatto che quando si usa un database relazionale ACID uno
> > vorrebbe cha ppunto fosse relazionale e ACID (MyISAM anybody?).
>


> MySQL è un db più general purpose ;) puoi decidere il pH.
>

???



>
> > E si, sono d'accordo con te che sia veramente una brutta opzione.
> Peccato faccia parte di ANSI SQL ;)
> https://en.wikipedia.org/wiki/Isolation_(database_systems)#Isolation_levels


E ancora una volta... ??? Cosa c'entra "peccato che" e cosa centra lo
standard.
Gli standard ti dicono *cosa* devi supportare, non ti dicono quanto sia una
buona idea usare una determinata feature per risolvere un determinato
problema.


> > Visto e considerato che MySQL fa abbastanza schifo di suo, se non
> interessa nemmeno
> > il poco che offre, tanto vale usare qualcosa che almeno sia piu'
> leggerino.
> Vabbé, siamo alla calunnia :D
>
> A parte scherzi, con la 5.7 stanno migliorando molto. Il problema è il
> numero di 5.1 ancora in giro...
>

Variazioni della frase: "con la ${v2} stanno migliorando molto. Il problema
e' il numero di ${v1} ancora in giro... " le sento da tipo 15 anni. 15
forse no... 10? Boh, ho perso il conto. Forse il fatto e' che la ${v2},
sebbene faccia cacare meno della ${v1}... come dire, eh?

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

Re: [Python] MySQLdb connect non aggiorna i dati sui client

[enrico franchi]

2016-03-02 10:02 GMT-08:00 Giuseppe Costanzi :

> http://dev.mysql.com/doc/refman/5.0/en/innodb-consistent-read.html
>

Questo pero' non e' quello che hai descritto nel primo post.


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

Re: [Python] MySQLdb connect non aggiorna i dati sui client

[enrico franchi]

2016-03-02 6:28 GMT-08:00 Carlos Catucci :

> Di solito l'ORM provvede ad aprire e chiudere (se non istruito
> diversamente) le transazioni senza doveri preoccupare della cosa. Almeno
> con Django, SqlAlchemy e un paio di robi PHP e Java non mi sono mai dovuto
> sbattere poi troppo.


Scusa ma... anche se scrivi normalmente con le dbapi a manella non ho visto
questo problema scrivendo il codice in modo un minimo umano. Certo che poi
se uno schianta il connector al db in una variabile globale, per dire...


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

Re: [Python] R: Re: R: Salve a tutti, sono nuovo.

[enrico franchi]

2016-03-01 4:18 GMT-08:00 Paolo Di Ieso :

> Detto questo, no top-posting, please.
> Se guardi il messaggio noterai si è perso il filo logico.
>

Gia' che ci siamo, quotiamo a modo... per esempio, concordo interamente o
comunque non ho da commentare le altre parti del tuo messaggio. Per cui
replico solo a quella che mi interessa, tagliando il resto. E nello
specifico, sono d'accordo con il "no top posting", ma ho anche rimosso le
altre parti del messaggio che non erano di interesse per questo ramo. :)


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

Re: [Python] Salve a tutti, sono nuovo.

[enrico franchi]

2016-03-01 10:12 GMT-08:00 :

> Grazie mille Carlos per la rapida risposta e per l'aiuto!
>

Quale parte di "No top posting" non era sufficientemente chiara?


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

Re: [Python] (Franx) Zappa

[enrico franchi]

On Tue, Mar 1, 2016 at 3:14 AM, Christian Barra  wrote:

> Docker :)
>

Anche questa e' un opzione. Non capisco perche' il top quoting cinofallico,
ma tant'e'.

Il problema di Docker e' che *non* risolve tutti i problemi. Semplifica
probabilmente il problema di gestire le quote e le risorse. Semplifica
anche determinati problemi di deployment dell'applicazione. Ma di per se
non fa nulla per ha o scaling.

Oltretutto se vuoi orchestrare applicazioni diverse su roba multi-tenancy
potresti avere bisogno di un po' di automazione smart. Se poi vuoi
introdurre ha e compagnia, e' probabile che devi pensare ai vari
orchestration framework e diventa tutto meno divertente.


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

Re: [Python] (Franx) Zappa

[enrico franchi]

2016-03-01 2:31 GMT-08:00 Marco Passanisi :

> Partiamo da un punto fermo, non devo scrivere niente o meglio scrivere
> poco cercavo qualcosa che mi consentisse di creare una classica linux box
> con Nginx -> Uwsgi -> app isolando gli utenti, come hai detto tu un sistema
> multi-tenancy, che li rendesse autonomi.


Ok, quindi lambda e' proprio una cosa diversa. E qui il punto chiave e'
quanta automazione vuoi.

Mi spiego... un conto e' che tu gestisci "manualmente" i 5-10 utenti
(ovvero in questo caso gli owner delle applicazioni) della tua azienda e
servi tutto da un solo webserver [o ancora piu' facile *tu* sei l'owner
delle 5-10 applicazioni]. Stesso scenario, ma 100 applicazioni diventa piu'
complicato.

Se invece vuoi un sistema tipo la gente "self-service" serve le loro
applicazioni dal tuo webserver, hai bisogno di molta piu' automazione e
molta attenzione alle varie quote. Si puo' fare, intendiamoci. Ma e' molto
piu' complicato. Se ci pensi ci sono aziende che come business fanno
esattamente questo.

Poi detto fra noi, nel 2016 non me la sento molto di consigliare "un server
che serve 10 applicazioni". E 'un availability risk immenso (anche per roba
tutto sommato poco critica). Preferisco di gran lunga virtualizzare 10 VM
piccoline, se proprio devo. E ovviamente farei *almeno* una ridondanza
active standby (o meglio ancora active-active o meglio ancora N+1 o
addirittura N+K). Ma mi rendo conto che N+K e' probabilmente un overkill (e
soprattutto e' qualcosa che ti interessa non solo per high availability, ma
anche per scaling. Ovviamente la cosa da tenere in considerazione e' per
andare su N+K, N+1 o anche solo Active + Active (che di fatto e' come dire
1+1) la tua applicazione deve essere pensata per quello (specificamente
deve essere stateless o usare qualche tipo di sticky loadbalancing con
tutti i problemi che ne conseguono). Active-Passive e' piu' facile da
mettere in piedi, ma ovviamente non consente di scalare altro che
verticalemnte (che ovviamente funziona fino ad un certo punto e basta).

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

Re: [Python] (Franx) Zappa

[enrico franchi]

2016-02-27 12:40 GMT-08:00 Carlos Catucci :

> https://gun.io/blog/announcing-zappa-serverless-python-aws-lambda/
>
> Che ne pensate? Visto che si parla di AWS e abbiamo una persona che lo
> conosce benissimo, sarebbe bello leggere qualche parere.
>

Se parlavi di me, sfortunatamente ho un conflitto di interessi per cui non
posso davvero esprimere opinioni. Quello che posso suggerire e' di leggere
la documentazione del servizio (che e' pubblica).

Bisognerebbe vedere se (e "quanto") Lambda e' incluso nel free tier per
giocarci. Se i limiti sono sufficienti per provare questo Zappa, e'
chiaramente possibile giocarci. Non ho trovato nulla in proposito, quindi
forse e' il caso di contattare il supporto.

Detto questo, se poi uno vuole usare Zappa in produzione, suggerirei di
parlare con qualcuno per capire quanto aspettarsi in termini di costi per
l'insieme applicazione "tua" + zappa su Lambda.

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

Re: [Python] (Franx) Zappa

[enrico franchi]

2016-02-27 21:59 GMT+00:00 Marco Passanisi :

> Salve a tutti, scusate se mi inserisco a gamba tesa :-),
>

Perche'? Non c'e' problema.


> ma vorrei chiedervi senza andare troppo fuori tema come si potrebbe
> implementare un servizio tipo Lambda ovvero dare ospitalità ad applicazioni
> web in Python su un server ad utenti diversi.
>

Secondo me non ti e' chiaro cosa sia Lambda. Hai provato a scorrere la
documentazione ufficiale? Anche solo l'introduzione.
Detto questo, si, e' possibile fare *tutto*. Poi che tu ti metta li e lo
scriva in tempo utile da solo e' un'altra questione.


> Per certi versi qualcosa anche di simile all'hosting classico di
> applicazioni php.
>

Che non ha assolutamente niente a che vedere con Lambda. Quindi cosa stai
chiedendo? Se puoi scriverti in casa Lambda (tecnicamente si... ma ci sono
un sacco di considerazioni a margine). Se puoi scriverti un sistema per
fare multi-tenancy in Python? Ancora una volta, si. Ma dovresti avere un
po' di conoscenze intorno a sta roba e anche capire esattamente cosa vuoi
fare e quanto disciplinati sono i tuoi tenants e quanto vuoi fare enforcing.


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

Re: [Python] Domanda stilistica

[enrico franchi]

2016-02-24 11:00 GMT+00:00 Marco Giusti :

> Io lancerei un'eccezione. Alcuni potrebbero non essere d'accordo con me,
> ma trovo le eccezioni chiare e autoesplicative se ben usate.
>

In questo caso e' estremamente difficile essere in disaccordo...

Le eccezioni vanno gestite comunque. Potrebbe esserci sotto un network
error o qualche altro errore che dice che non e' che le credenziali sono
invalide, ma qualcos'altro si e' spaccato (=> retry, maybe... dipende da
cosa). Ovviamente non c'e' modo elegante di codificare questo *in Python*
che non siano le eccezioni.

Si potrebbe dire che in questi casi tiri l'eccezione e se l'autenticazione
e' invalida usi un valore di ritorno... e il codice diventa un po' piu'
scomodo (poiche' bisogna gestire che il token sia None).

Nota per OP: se vai con i valori di ritorno, False e' sbagliato
chiaramente. None e' accettabile. Se il tuo token e' un oggetto "ricco",
potresti valutare un NullObjectPattern. Ma comunque lo fai, rimane piu'
complicato da usare che semplicemente usare le eccezioni anche per questo.

Collassare tutti gli errori possibili nel valore di ritorno e' pure un
errore. Insomma... direi che qui le eccezioni sono proprio lo strumento
giusto.


>
> Perché non ritornare un valore che sia esterno all'insieme dei risultati
> possibili? La prima volta che tu, o un altro per te, dimentica di
> controllare il valore di ritorno della funzione, è possibile che
> eccezioni del tipo "TypeError: unsupported operand type(s) for +:
> 'NoneType' and 'str'" vengano sollevate. Questo nel migliore dei casi,
> perché se per un caso molto strano quel "None" finisce nel DB, potresti
> fornire a tutti gli "sconosciuti" la stessa sessione.
>
> Un bel AuthError invece è chiaro e può essere facilmente gestito ad un
> livello superiore.
>

Concordo anche su queste considerazioni. Aggiungo che, in generale, e'
cattiva pratica avere una funzione che ritorna valori che non supportino
un'interfaccia (in senso lato) comune. Per esempio se mi aspetto che mi
ritorni un file-like su cui posso scrivere, mi aspetto che qualunque cosa
mi torni abbia il metodo write (e cosi' via). Una funzione che ogni tanto
ritorna stringhe, ogni tanto numeri, ogni tanto paperelle lascia sospetto.

None e' un po' l'edge case... fondamentalmente non supporta un tubo, ma
almeno si testa facilmente che e' proprio None. ovviamente complica il
codice costringendo fastidiosi if. Da cui il NullObjectPattern (che
ovviamente usato a cazzo non va bene manco lui). None e' proprio un
obrobrio che ci si porta dietro da troppo tempo in troppi linguaggi perche'
il type system e' troppo debole o troppo poco espressivo... ci sono pezze
(Optional) che hanno un prezzo ben diverso da un sano vecchio Maybe. Hoare
ne rivendica la paternita' (di Null/None o come vuoi chiamarlo) e lo
considera anche un errore che e' costato milioni di dollari all'industria.


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

Re: [Python] Da PostgreSQL a AWS RDS

[enrico franchi]

2016-02-18 9:18 GMT+00:00 Christian Barra :

> Ho sempre avuto l'idea inversa, cioe' rimanere in cloud fino a quando sei
> piccolo e poi muoverti verso una soluzione su bare machine,


Nella pratica sul cloud ci sono entita' di tutti i tipi, dai piccoli
piccoli piccoli fino ad aziende estremamente grosse.

> con docker oggi faresti anche a meno delle vm.

Io direi che sono due cose piuttosto separate. Direi anche che, salvo casi
molto specifici e un po' ad hoc non sono particolarmente sostituibili:
risolvono uno spazio di problemi diversi.


-- 
.
..: -enrico-
___
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?

[enrico franchi]

2016-02-11 18:07 GMT+00:00 alessandro medici :

> 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

Re: [Python] Pandas ed Encoding

[enrico franchi]

2016-02-09 11:19 GMT+00:00 Pietro Battiston :

> Sarei curioso di sapere cosa ti abbia dato questa impressione al volo.
> Es. disorganizzazione del flow? Pochi commenti? Troppe funzioni a spasso?
> Tutto ciò ed altro?
>

Mah... un insieme di cose. Intanto non sono mai stato contento dell'API.
Tenta di essere smart in molti modi e risulta essere semplicemente
complicata da usare.

Ovviamente questa tendenza se la portano in giro un po' ovunque... per cui
per dire hai signatures veramente inbordellate. Tipo a sboccio i readers
hanno una cinquantina di parametri. E per risolvere il problema della code
duplication fanno una higher order function (di 50 parametri) che ti
ritorna una funzione (di 50 parametri) che fa un minimo di parameter
mangling, poi ci costruisce un dizionario gigantesco che passa come
argomento alla funzione effettiva "generica" che fa il lavoro. La quale
funzione e' lunga tipo 260 righe.

Ora... hai due approcci per testare tutto questo. O testi solo le funzioni
"pubbliche" (e.g., read_cvs), oppure testi la funzione effettiva _read. Che
ha 50 parametri. Ora, nell'ipotesi semplificativa che ciascuno di questi
parametri abbia due valori rilevanti, stiamo parlando di 2^50 combinazioni
di input. Che e' nell'ordine di grandezza di mille volte l'eta'
dell'universo. Ora, non e' detto che tutte le combinazioni percorrano path
diversi (ovviamente impossibile, visto che la funzione e' solo 260
righe)... ma allora perche' non raggruppare i parametri in pochi set noti?
Se invece testi solo la roba pubblica, rischi di lasciare combinazioni non
testate che magari mordono. Mi sembra che qualcuno si sia scordato di
provare a modellare sta roba ad oggetti... ecco.Non che sia un gran fan
della programmazione ad oggetti... ma anche in Haskell se uno vede gruppi
di parametri che vanno insieme si fa una qualche struttura che li
rappresenta.


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

Re: [Python] Riflessioni su anni e compensi (was Pythonista wanted a Pisa)

[enrico franchi]

2016-02-06 13:05 GMT+00:00 Carlos Catucci :

>
> 2016-02-06 13:50 GMT+01:00 Enrico Bianchi :
>
>> Differente è il nostro caso, dove si tratta più di un lavoro
>> intelletuale, e quindi la discriminazione dovrebbe essere fatta dal basso
>> (più si è anziani, più si è esperti).
>
>
> Che poi dipende. Non so di preciso quanti anni abbia ad esempio Riko ma
> direi molti meno di me, eppure lui ha dimenticato piu' roba di quanta io
> abbia imparato.
>

Si, senza dubbio meno anni di esperienza. Poi su quello che dimentico,
imparo, etc etc etc... ognuno valuti a modo suo. ;)
Indubbiamente ho meno anni di esperienza.

Per l'altro Enrico... "piu' si e' anziani, piu' si e' esperti". Boh... sai,
se uno per 20 anni ha messo in produzione il sito LAMP fatto con Joomla non
e' che sia "piu' esperto" di uno che in 4 anni ha messo in piedi l'intera
l'infrastruttura di 2 startup. Se uno per 20 anni ha scritto dei gran bean
per l'application server del momento non e' che necessariamente abbia sta
grande esperienza di sviluppo.

Gli anni di esperienza sono un vantaggio se uno li ha riempiti di
esperienza vera e non e' stato nel proprio giardino. Se uno fa sempre la
stessa roba, il "ritorno di esperienza" ad un certo punto si azzera. Non
solo: si ha qualcuno che rischia di essere fossilizzato su 10 anni prima.
Insomma, l'esperienza si misura nel peso e nel numero dei progetti e nella
loro differenziazione, non nel numero di anni.

Il problema di fondo è sempre lo stesso: il 20enne/30enne costa meno di un
>> 40enne o più, e quindi si tende a mettere questi paletti
>
>
> Certo di solito il 20enne lo puoi prendere con contratti tipo
> apprendistato.
>

Boh... l'italia mi sembra cosi' demenziale sotto questo punto di vista. Qua
da noi i contratti permanenti sono la norma; il problema e' fare stare la
gente valida a lungo... quello si.


> Aveva ragione il nostro Daniele (Palmese) quando mi disse che in questo
> campo se vuoi campare decentemente crivendo codice devi scrivere roba tua
> da vendere, che se lavori per altri non ci esci.
>

Se vuoi restare in Italia, forse. E anche scrivere roba "da vendere" vuole
dire tutto e nulla. Puoi vendere un prodotto o un servizio. Sono due cose
completamente diverse. E poi... come prendi i soldi? Vuoi finanziamenti e
sperare di "esplodere" oppure vuoi vendere il gestionale customizzato ai
vari customer? Sono due business model completamente diversi. Con il primo
"fai i soldi" (se ti va bene), con il secondo non necessariamente guadagni
piu' che essendo una persona "di fascia alta" per terzi (e hai tutta una
serie di problemi nella ricerca del cliente, avere i pagamenti, etc etc
etc). D'altra parte il modello startup rischia di finire con un nulla di
fatto monetario (e solo un ritorno di esperienza).


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

Re: [Python] Pandas ed Encoding

[enrico franchi]

2016-02-08 18:58 GMT+00:00 Christian Barra :

> I dati contenuti sono sempre gli stessicon "b" cosa intendi ? Da
> python b'stringona' ?
>
>>
A me verrebbe da dire che se df_1 = pd.read_csv(URL, encoding="latin-1")
fallisce (ovvero non fa quello che vuoi) vuole dire che:
1. c'e' un baco in pandas
2. c'e' un baco in urllib2 (usi Python 2?)
3. il file che ti arriva effettivamente non e' in latin-1

Senza fare analisi binaria di quello che ti arriva, e' complicato risolvere.

BTW, il codice critico e' qui:
https://github.com/pydata/pandas/blob/master/pandas/io/common.py

e la roba inizia qui:
https://github.com/pydata/pandas/blob/master/pandas/io/parsers.py#L244

Non mi ero accorto mai di quanto facesse cacare il codice di Pandas, per
inciso.

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

Re: [Python] [SEMI-OT] Consigli per un manager di file SQLite ?

[enrico franchi]

2016-01-27 11:08 GMT+00:00 salvatore monaco :

> lo provo
>

potresti anche provare a quotare in modo umano?


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

Re: [Python] Fwd: [Bologna-xpug] The sad state of web development

[enrico franchi]

2016-01-20 9:58 GMT+00:00 Patrick Guido <patrick.armi...@gmail.com>:

> On Wed, Jan 20, 2016 at 1:34 AM enrico franchi <enrico.fran...@gmail.com>
> wrote:
>
>> Ma e' colpa nostra: c'era evidentemente un buco di tooling grosso come
>> una casa su tutta la catena... node.js l'ha riempito. Colpa di tutti noi
>> altri che ci siamo mossi tardi. Fare qualcosa ora? Prima devo farmi
>> approvare la giornata di 72 ore, che 48 vanno per il solo lavoro...
>>
>
> Scusatemi, mi consigliate qualche link che parla dei problemi di node e di
> Javascript?
>

Guarda, ce ne e' a pacchi in rete. Consigliartene uno specifico? Posso
anche farlo, ma non sono sicuramente il personaggio piu' up-to-date della
storia nella lettura dei blog.

Allora, andiamo per gradi... problemi di Javascript. Credo che l'ottimo
"The Good Parts" sia piuttosto chiaro nell'indicare una buona sequenza di
problemi. In generale il fatto stesso che hai bisogno di restringere cosi'
tanto la parte "buona" e' un sintomo che di roba che non va ce ne e'
parecchia.

Tra l'altro, finche' non rompono la compatibilita' (e sappiamo tutti che e'
improbabile riuscire a farlo con successo) la merda resta. Insomma, non e'
come la situazione che aveva Java qualche tempo fa [ovvero mancanza di
feature che rendevano tutto davvero troppo legnoso]. Il problema di
Javascript e' che da un lato nelle versioni "tradizionali" mancano features
strutturate utili (oh merda... ma davvero sono l'unico che trova bislacco
dovere fare quel troiaio che suggerisce Crockford per creare un *modulo*
perche' il concetto di modulo, di fatto, non esiste?), ma soprattutto nel
linguaggio sono finite un sacco di cattive idee che non ci sarebbero dovute
finire (veramente Good Parts spiega la maggior parte di queste).

Node.js? A me ha divertito molto questo:
https://www.semitwist.com/mirror/node-js-is-cancer.html
Ma e' vecchio. Comunque molti dei problemi elencati sono filosofici. Ancora
piu' interessante e' come la comunita' reagisce alle critiche. Il che mi fa
solo venire voglia di starne lontano.

Personalmente lavoro molto su frontend ma non mi sento di concordare con il
> primo articolo. Si è vero che ci sono un'infinità di tool per fare lo
> stesso lavoro, ma credo che sia normale per il momento in cui siamo.
>

Ecco... io credo che sia *non* normale. O meglio, che sia una cosa da
rettificare al piu' presto. Sono pagato per consegnare cose fatte.
L'evoluzione darwiniana di un ecosistema di sviluppo e' un problema che
preferirei trattare da accademico, non doverci lottare come ingegnere.

Tra l'altro... non e' che sia da poco tempo che il software engineering
tratta il problema di gestire le dipendenze in progetti software. Quello
che e' lo standard nel mondo di node si *sa* che e' disastroso.

Questo lasciando stare il fatto stesso che node.js e' un tool che gira su
Unix, in essenza, ma che ignora quasi completamente tutta la storia di
Unix. E' un mondo a parte, in un certo senso come la JVM. Ma mentre la JVM
e' molto strutturata e costituisce un sistema essenzialmente completo e
autocontenuto (che e' una brutta e una bella cosa a seconda di come lo si
vede), node.js ha un'approccio parziale. Abbiamo gia' visto che gli
approcci parziali creano problemi (in Python se ne manifestano), ma almeno
Python e' relativamente regolare nel resto (il che vuole dire che e'
piuttosto facile "mappare" Unix <-> Python). La stessa cosa non avviene con
Node.

E' un mondo a se che segue regole sue, che pero' non sono state validate
nel corso degli anni.

In fondo stiamo un po' affrontando una rinascita di Javascript (anche con
> le nuove specifiche del linguaggio).
>

Mah... direi che Javascript non e' mai "morto".


> Poi, boh, magari sono io *cieco* e non riesco a vedere tutti questi
> problemi, ma davvero vorrei cercare di capire :)
>

Immagino che dipenda da quello che devi fare.

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

Re: [Python] Fwd: [Bologna-xpug] The sad state of web development

[enrico franchi]

On Tue, Jan 19, 2016 at 1:16 PM, Patrick Guido 
wrote:

> On Tue, Jan 19, 2016 at 12:41 PM Carlos Catucci 
> wrote:
>
>> Che ne dite?
>>
>
> Consiglio di leggere anche questo prima :)
>
>
> https://medium.com/swlh/the-sad-state-of-entitled-web-developers-e4f314764dd
>

Non ho capito il punto dell'autore. Mi sembra che quello che dice e' che
Drew non avrebbe dovuto scrivere nomi e cognomi e che per il resto e' colpa
di tutti e colpa di nessuno e prima o poi qualcuno ci salvera'. Kumbaya!

Ora, detto fra noi fra il politicalmente correttese che trasudava il post
(fortunatamente tengo nel cassetto degli anti-emetici per essere pronto
anche alle pull request piu' ardite) e il segnale informazione/rumore nullo
mi sono trovato un po' fregato...

Anche perche' non ha capito il problema fondamentale: il post originale non
era un rant su uno specifico software (che appunto, che ci vuole, faccio
una pull request e via) ma contro un delirio collettivo di kool kids e
aziende tutti aggrovigliati in questa spirale di dimentichiamoci di qualche
decennio di software engineering. Ora contro una folla delirante non c'e'
pull request che funzioni. E si, in una cosa ha ragione: non e' colpa di
nessuno, perche' e' proprio colpa di tutti.

Prima o poi, spero, che la gente rinsavisca. Anche se, la mala erba non
muore mai. PHP ancora se ne va in giro. Mannaggia, avevo un altro paio di
frecciatine caustiche su PHP ma poi tutti questi vapori di politically
correct che trasudano di questi tempi mi hanno investito. Mi sa che ormai
per scrivere come mi pare devo fare in modo che nessuno legga... se no
prima o poi qualcuno si offende. Comunque... dicevo, io temo che ormai
node.js non ce lo leviamo piu' dalle palle.

Ma e' colpa nostra: c'era evidentemente un buco di tooling grosso come una
casa su tutta la catena... node.js l'ha riempito. Colpa di tutti noi altri
che ci siamo mossi tardi. Fare qualcosa ora? Prima devo farmi approvare la
giornata di 72 ore, che 48 vanno per il solo lavoro...





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

Re: [Python] Fwd: [Bologna-xpug] The sad state of web development

[enrico franchi]

On Tue, Jan 19, 2016 at 11:41 AM, Carlos Catucci 
wrote:

> Che ne dite?
>

Che concordo in toto. node.js e' un esercizio di stile in cattive idee.

Dopo di che e' noto: quando hai un problema, introduci un layer di
astrazione.
Lavori in javascript con node.js? le fondamenta sono un problema, ogni
layer e' un problema: conseguenza, ad un certo punto si accorgeranno che
per quanto si stiano sforzando non potranno creare infiniti layer di
astrazione, abbandoneranno tutto e qualcosa di non cosi' marcio si
affermera'.



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

Re: [Python] Python Anagram Contest was Tesseract

[enrico franchi]

2016-01-11 7:39 GMT+00:00 Andrea D'Amore :

> Oh, io ho "starrato" il dizionario e ho unito i file, ma che
> dizionario italiano è quello che ha tutte le singole lettere
> dell'alfabeto tra i lemmi insieme a "roof" e "road"?
>

Beh, l'autore riporta i criteri secondo cui l'ha compilato...

Dopo di che, le singole lettere mi sembra corretto che ci siano. A "noi"
non fa comodo, ma per la lingua italiana sono parole valide (le parole che
si usano per denotare le suddette lettere...).

Per le parole straniere, ha spiegato il criterio secondo cui le ha incluse.
Non sono sicuro che sia ottimale per noi, ma non volevo spendere due vite e
mezzo a fare review del miglior dizionario... ;)


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

Re: [Python] Python Anagram Contest was Tesseract

[enrico franchi]

2016-01-10 16:07 GMT+00:00 Giovanni Porcari :

> Pisciava orrore
>

Inarrivabile. Adesso confessa pubblicamente che lo hai chiamato Saverio
apposta per questo. ;)


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

Re: [Python] Tesseract

[enrico franchi]

2016-01-09 14:44 GMT+00:00 Marco Beri :

> On Sat, Jan 9, 2016 at 3:33 PM, Carlo Miron  wrote:
>
>> 2016-01-09 15:23 GMT+01:00 Marco Beri :
>>
>> > 2016-01-09 15:15 GMT+01:00 Esalando Prassi <
>> alessandro.p...@katamail.com>:
>> >
>> > Raffinaterrimo nickname :-)
>> >
>> > Ciao.
>> > Marco Beri aka Reimbarco.
>>
>> o Cero Rimba.
>>
>
> Non esiste la seconda parola, caro il mio Colmo Narri.
>

Vai, sfida!

Utilizzando le parole da
http://www.yorku.ca/lbianchi/italian_words/italia-1a.gz scrivere un
programma che fa anagrammi costituiti da parole valide secondo il
dizionario.

A disposizione: solo la libreria standard (Python 2.7 o Python 3.5)

Categorie:
- il piu' corto (lunghezza, wc -c del file)
- il piu' veloce
- il piu' efficiente computazionalmente (complessita' computazionale, non
velocita' pura)
- il piu' pythonico (stile, PEP8, zen)

Vogliamo altre categorie?

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

Re: [Python] accesso ad hard disk esterno

[enrico franchi]

2016-01-06 14:01 GMT+00:00 Manlio Perillo :

>
> No.
> Il problema del Settembra Eterno riguarda una comunità di elite
> sommersa da gente comune.
> Ma oggi con forum e mailing list non esiste più l'elite (intesa come
> comunità ristretta e controllata) perchè praticamente tutti hanno
> accesso ad internet.
>

Dipende un po' come vuoi vederla. Nello specifico, la prima volta che il
problema dell'eterno settembre si e' manifestato era una piccola community
di gente ben educata sommersa da gente male educata (o non educata
affatto). O meglio... erano abituati ad essere sommersi in settembre dai
niubbi; la differenza e' stata che da li in avanti il flusso e' stato
costante.

Quindi per me il concetto di "eterno settembre" e' un flusso costante di
gente "niubba" che arriva in una community "ristretta" che fatica ad
integrarla nelle proprie norme sociali. In questo il mezzo (usenet vs.
altro) o la ragione (isp vs. altro) e' meno interessante rispetto
all'effetto netto, che e' lo stesso.

In altre parole, per me, non esiste piu' il "pre"-eterno settembre. Il
settembre normale, insomma. Le community tendono ad essere quasi sempre in
eternal september mode. C'erano ovviamente eccezioni: per esempio quando
Python era di interesse per una relativa minoranza, non c'era in giro
Django e non veniva fatto in universita', la faccenda era molto diversa.
Hey, io e te c'eravamo. Sia qui sia su usenet. Arrivavano "pochi" nuovi
utenti per volta e verosimilmente era gia' gente che si sapeva muovere su
internet.

Adesso che siamo tutto sommato mainstream, che abbiamo librerie di largo
traino che portano gente con un background diverso (django, ma per certi
versi anche la roba per data science, o altre librerie che fanno da ponte),
che viene fatto in universita' (quindi flusso di studentelli "comuni")... a
me sembra che siamo in costante modalita' settembre eterno. Guarda la
demografica della ML e dimmi te...

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

Re: [Python] accesso ad hard disk esterno

[enrico franchi]

2016-01-05 20:54 GMT+00:00 Manlio Perillo :

>
> Direi che il problema del Settembre Eterno è stato risolto, con la
> morte di Usenet.
>

Io direi che si e' spostato altrove, forum, mailing list...


> Peccato che i problemi si risolvano sempre nel modo sbagliato.
> Mi viene da pensare alla soluzione ad uno dei "problemi" di Stroustrup:
> "I have always wished for my computer to be as easy to use as my
> telephone; my wish has come true because I can no longer figure out
> how to use my telephone"
> http://www.stroustrup.com/bs_faq.html#really-say-that


Oh, interessante. Guido e Kernighan come se la cavano con i telefonini?
Magari c'e' una correlazione misteriosa fra linguaggi che mi piacciono e
abilita' d'uso dei telefonini. Secondo questa tesi Lerdorf dovrebbe stare
usando ancora un telefono a ghiera...

Investigare...

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

Re: [Python] AA Cercasi Pythonisti Padovani !

[enrico franchi]

2015-12-07 19:04 GMT+00:00 Manlio Perillo :

> La cosa che mi lascia perplesso è che il quoting errato lo vedo anche
> su mailing list molto tecniche come golang-dev, e da parte di
> programmatori *esperti*.
>

Guarda, dipende dalle "convenzioni" e dagli strumenti che si usano. Se
golang-dev ha deciso che non c'e' una policy (o addirittura ha deciso che
la policy e' top quoting) *e* gli strumenti usati da buona parte delle
persone (o per lo meno da quelle con abbastanza autorita' da fare passare o
bloccare una convenzione) supportano bene lo use-case, non e' che ci sia un
grosso problema.

Tipo se una ml e' in realta' intesa per essere leggere letta con
google-groups (o come cavolo si chiama) e di fatto quindi il 90% della
gente la usa in quella maniera, e' anche possibile che per determinati
messaggi la cosa giusta sia *non* fare quoting corretto perche' per come
funziona lo strumento strategie piu' semplici funzionano meglio. L'altra
questione e' quanto branching ci si aspetta in media.

La cosa importante e' concordare su un set di regole.

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

Re: [Python] AA Cercasi Pythonisti Padovani !

[enrico franchi]

2015-12-07 17:36 GMT+00:00 Christian Barra :

>
> Che ne dite ?
>

Ne dico che veramente *basta* con il top quoting. Sembra diventata una
mailing list di altro tipo.

Credo che ormai il cosiddetto Python Paradox si possa considerare
definitivamente morto.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] AA Cercasi Pythonisti Padovani !

[enrico franchi]

2015-12-07 17:29 GMT+00:00 Kbyte :

> Veramente in ambito "informatico" sono veramente pochi che usano quella
> piattaforma, a mio avviso del tutto inutile dato che ne esistono decine
> anche free ugualmente deserte.


Qua a Dublino e' lo standard per tutti.


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

Re: [Python] Python e cluster di raspberry

[enrico franchi]

2015-12-06 12:17 GMT+00:00 Fundor333 :

> Il 06/12/2015 12:43, Valerio Maggio ha scritto:
>
>
> Tutto qui: non si tratta di instabilità. La API rilasciate sono
> *naturalmente* stabili.
> Un esempio di confronto tra Python e Scala.
>
> Come ci era stato presentato le API python sono soggette a grossi
> cambiamenti in quanto ci stanno ancora lavorando sopra
>

Guardatevi un po' di changelog per capire cosa aspettarvi.


>
> Quindi, se capisco bene, vuoi mettere su un cluster di raspberry pi su cui
> far girare Spark?
> Ripeto: deve sempre essere possibile eseguire la JVM, eh?! Non
> dimenticarlo.
> Torno a dire: Spark è implementato in Scala. Tutto diventa Scala, alla
> fine della fiera.
>
> Questo lo sappiamo bene. Infatti noi, avendo del codice python volevamo
> partire da quello sopratutto perchè abbiamo già confidenza con le librerie
> necessarie
>
> Scusa... ma le "librerie necessarie" sono quelle di spark. Quindi?



> Su C#, niente da dire (nel senso che non reputo *fondamentale* conoscere
> il C#)
> Ma intendi dire che sei uno studente di Informatica all'università e non
> conosci almeno uno tra C o C++?! O_o
> Su questo, qualcosina da dire ce l'avrei, btw.
>
> No non è che non lo so. E' che per un progetto che viene fatto a tempo
> perso con poca esperienza in C e praticamente nessuna in C++ ha poco
> senso farlo quando invece siamo molto più pratici con Python e Java.
>
> Ma scusa... parliamo di un coso Scala su JVM... chiaramente Java e Scala
sono scelte sensate. Python? Se capite che quello che vi interessa e'
supportato, buona. Ovviamente tutte le volte che si e' un po' fuori dal
seminato bisogna cavarsela un po' da soli. Dipende se avete voglia, come
confrontate il fatto che Python sia probabilmente un po' piu' svelto da
scrivere e lo conoscete meglio con il fatto che trovate meno supporto. Ma
solo voi sapete quanto usare Python per voi sia un vantaggio e quanto
abbiate tempo e voglia di dovere gestire un caso meno popolare.


> Infatti dopo progrmmazione nessuno ti fa scrivere più in c programmi se non 
> qualche funzione su qualche corso.
>
>
Si, ma non vi aspettate che tutto e solo quello che si fa in universita'
sia sufficiente per andare la fuori. Non ti fanno abbastanza C? Fattelo da
solo. Non ti interessa conoscere C? Boh, di questi tempi magari te la cavi.
Chissa'. Con una buona scelta su cosa vuoi fare davvero magari funziona
anche come scelta.


> Invece stiamo lavorando per tirocinio in python per cui siamo più pratici e 
> abituati a usarlo
>
> Ok.


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

Re: [Python] Dimmi tre libri informatici che non si può non aver letto

[enrico franchi]

2015-12-03 14:31 GMT+00:00 Manlio Perillo :

Forse un libro che aiuta un informatico a fare meglio il suo lavoro?
>

Eh, ma e' proprio questo il problema. Ci sono tanti tipi diversi di lavoro
che finiscono sotto.
Puoi essere uno sviluppatore (e anche qui... frontend, full stack, devops,
back end... system programming, desktop applications, mobile, web, etc),
puoi essere un system engineer, un tpm, un lavoro ibrido dev e mgmt. Puoi
essere un ricercatore (accademico oppure R).

Per quello ho cercato di restringermi a roba che "piu' o meno" serve per
tutte le parti tecniche. Ovviamente ho lasciato fuori (apposta) competenze
strettamente di gestione progetto/mgmt. Ho anche lasciato fuori roba "solo
teorica", ho lasciato fuori ui design e human interaction, ovviamente.
Apposta, intendo. E certamente la selezione che ho fatto non e' esattamente
ideale per tutti i ruoli la sopra. Per dire, sebbene sia tutto rilevante
per un mobile dev, manca anche tanto di specifico. per un frontendista (o
addirittura per qualcuno che faccia ui design) manca un sacco di roba e
molta roba non e' rilevante. Eh... non e' che PP sia troppo rilevante per
qualcuno che fa strettamente accademia: ci sono parti utili, ma anche parti
non troppo utili.

Purtroppo il problema di avere un denominatore comune non e' affatto banale.


>
> > [...]
> > Quindi:
> >
> > 1. SICP:
> > [...]
> > 2. The Linux Programming Interface:
> > [...]
> > 3. Pragmatic Programmer:
> > [...]
>
> Manca un testo fondamentale sull'interazione con l'utente, dato che la
> maggioranza dei software deve interagire con un utente che nella
> maggioranza delle volte non sa come il software funziona (e nemmeno lo
> vuole sapere).
>

Certo. Mancano anche altre cose: ho fatto in modo di restringermi a roba
che piu' o meno faccia comodo a tutti.
Non tutti i dev, specie ora che si va di microservizi hanno il problema
dell'applicazione "user-facing", per dire.


>
> Io ho letto l'ottimo Don't Make me Think, orientato al web.
> Di seguito ho comprato The Design of Everyday Things, ma la lettura
> procede a rilento perchè a differenza di Krug, il testo è lungo e mal
> si adatta ad una lettura di poche pagine al giorno.
>

Ha... DMT lo ho li da tempo. Leggerollo prima o poi.





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

Re: [Python] Dimmi tre libri informatici che non si può non aver letto

[enrico franchi]

2015-12-04 13:36 GMT+00:00 Manlio Perillo :

L'utente è anche lo sviluppatore che deve usare la tua API.
>

Per scrivere una buona API mi verrebbe da dire che e' sufficiente capire le
architetture su cui ti basi (e.g., e' un API rest? un'api ad oggetti per
una libreria? etc.). E' chiaro che non vuole dire che debba essere
complicata inuitilmente, ma DMT parla di usability web; secondo me non
tratta particolarmente questo use-case.


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

Re: [Python] Scam, truffe e raggiri vari... in salsa Pythonesca

[enrico franchi]

2015-12-03 8:29 GMT+00:00 Simone Federici :

se i bravi tecnici si mettono a fare gli hr avremmo comunque un problema.
>

hr != recruiting

E no, non ci sono grossi problemi ad avere le interviste fatte dagli
ingegneri. Anzi...


> i tecnici arrivano solitamente al 2 o terzo colloquio, e non mi sembra ci
> sia nulla di male.
>

Farei molto fatica a lavorare per un'azienda simile. Un conto e' fare
*scremare* ai non-tecnici (e.g., lista di domande a risposta chiusa che
loro possono verificare... ma anche questa cosa ha una marea di problemi).
Pero' in questo caso e' un dettaglio implementativo: l'intervista e'
comunque tecnica, semplicemente e' un non-tecnico che la svolge.

Ma non mi e' chiaro cosa debbano chiedermi sti "non tecnici" di rilevante
per l'assunzione che non siano cose logistiche. Ma in questo caso non e'
nemmeno un colloquio. Davvero... anche perche' tutta la distinzione
tecnica/non tecnica e' irrilevante: la maggior parte delle domande
behavioral interessanti hanno comunque bisogno di un tecnico per essere
capite.


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

Re: [Python] Kingping

[enrico franchi]

2015-11-29 18:21 GMT+00:00 Gollum1 :

Non ho più lo stomaco di una volta, senza condimento sgambettano troppo, e
> mi rimangono sullo stomaco.
>

Potremmo anche stabilire un concorso settimanale o mensile per "quoting
maggiormente cinofallico".
Tipo Edorardo qua e' andato veramente all in... per avere un perfect score
gli manca solo una singola frase di una riga aggiunta come commento a
qualche quoting di livello > 3 sparso nel body *e* un po' di sane gif
animate in firma...

Ma anche cosi' e' un contendente molto serio.



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

Re: [Python] Dimmi tre libri informatici che non si può non aver letto

[enrico franchi]

2015-12-02 14:15 GMT+00:00 Francesco Pischedda <
francesco.pische...@gmail.com>:

> Anche se sicuramente non è evidente (e mettiamoci anche che non ho dato
> spiagazione delle mie scelte), i libri che ho proposto sono stati scelti
> bene o male seguendo lo stesso ragionamento; pur indirizzati a problemi
> molto specifici (CG, AI, reti) secondo me riescono a dare un'idea generale
> di come si possano affrontare problemi reali usando lo strumento
> informatico, fanno vedere una marea di codice che non è mai male e, nel
> caso del libro sulla AI, insegnano anche le basi della programmazione
> (tramite lisp e un pochino di prolog).
>

Dici? A me sembra di no... a me sembra che magari sono libri che sono stati
estremamente importanti per la tua formazione e la tua crescita... ma di
sicuro non sono "particolarmente generali", tu stesso lo specificavi nel
tuo messaggio.

L'esempio piu' eclatante e' quello su computer graphics. Credo che per il
99% degli ingegneri sia un argomento su cui non ci sia assolutamente
bisogno. Poi per alcuni e' fondamentale, chiaramente. Sono anche convinto
che sia molto divertente [personalmente, sono uno che apre un terminale in
ssh e quello e' il mio concetto di "grafica", ma ymmv].

Nota, questo non vuole dire che non sia un libro eccezionale. Ma guardando
il toc non vedo molto che "non mi interessa per nulla cg, ma quei 3
capitoli sono preziosissimi comunque". Mi sembra un libro mirato e
comprensivo su un singolo argomento. Argomento che oggettivamente impatta
una minoranza degli sviluppatori.

Reti? Io *vivo* sull reti. A tutti i livelli... *devo* sapere molto di
reti. Ma quello che serve a me e' molto di piu' di quello che serve
all'ingegnere software medio (perche' e' parte del mio business domain). A
suo tempo me lo lessi, ne ho una copia aggiornata di fianco al desk...
credo di non ricordare manco il 3% di quello che il libro contiene. Cioe',
e' utilissimo, figuriamoci... ma spesse volte va in dettaglio incredibile
su roba relativamente poco rilevante (per me), viceversa per la roba
rilevante magari dice tre scemate e si va di rfc e tanti saluti. E' un
cattivo libro? Assolutamente no. E' ottimo textbook sulle reti. Punto di
vista molto teorico, molto rigoroso e facile da leggere. Per l'ingegnere
medio? Fa solo bene averlo studiato, certo... ma se devo scrivere il mio
classico micro-service per la startup con cui faro' un sacco di soldi,
sperabilmente mi e' irrilevante sapere come funziona sonet. Diciamo che in
generale ci sono un sacco di cose interessanti che vengono prima.

AI? Salvo che non e' manco chiaro se AI sia CS, CS sia AI o siano
semplicemente due branche distinte... comunque, sullo specifico libro, che
lessi un po' di anni fa... i primi capitoli sono tutti su Lisp. Ora, Lisp
e' un linguaggio come un altro per imparare... sinceramente da un punto di
vista didattico preferisco scheme e da un punto di vista pratico preferisco
clojure... ma common lisp e' fico. Certo. Fa benissimo saperlo. Ecco,
diciamo che le parti non AI di quel libro mi sono piaciute molto. Le parti
AI? Boh, non ne capisco il fascino. Al 99% e' roba che nei casi semplici e'
fichissima e bellissima, nei casi reali pero' non credo che quasi nessuno
faccia AI classica fuori dall'accademia. Poi insisto... il modo in cui lo
fa Graham e' sempre fascinoso. Dopo di che e' un libro del '91. Lisp magari
non e' cambiato molto... la famosa parte "banale" dell'AI nemmeno. Roba
tipo natural language processing invece spererei che abbia fatto qualche
passo avanti in 25 anni. ;) Comunque diciamo che fra i tre e' possibilmente
l'unico che terrei in una lista di libri "limitata" [se invece avessimo dei
bucket 'per genere', quindi abbiamo il concetto di, che so, un libro di
reti, un libro di algoritmi, un libro di sistemi operativi, etc... beh, gli
altri due sono sicuramente fra i top tier della loro categoria].

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

Re: [Python] Scam, truffe e raggiri vari... in salsa Pythonesca

[enrico franchi]

2015-12-02 13:52 GMT+00:00 Carlos Catucci :

> il mercato interno di Dublino e' saturissimo e spietato
>
>
> Yes ma lo strascico non porta buona pesca.
>

Dipende quanto offri...


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

Re: [Python] [OT] unittest scritta in C

[enrico franchi]

2015-12-02 16:52 GMT+00:00 Marco Giusti :

> Visto che ti sei preso la briga di leggerti il codice, tu solo hai una,
> parziale, risposta alla domanda di Marco Beri.
>

Domanda che pero' non mi e' pervenuta...


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

Re: [Python] Scam, truffe e raggiri vari... in salsa Pythonesca

[enrico franchi]

2015-12-02 11:37 GMT+00:00 Raffaele Salmaso :

> 2015-12-02 12:26 GMT+01:00 Francesco Maida :
>
>> Stamani mi è arrivata un'email da un sedicente tizio di Zalando.
>> Nella lettera scrive che ha notato su Github la mia maestria nell'uso di
>> Python e vorrebbe contattarmi per un lavoro con loro.
>>
> A me è arrivata perché ha visto i miei numerosi lavori in java...
> Che sono nella sezione privata di bitbucket perché di clienti...
>
> Vabbé, passiamo oltre :D
>


Sinceramente non credo che sia uno scam. Zalando e' un'azienda esistente
(sono anche stato nei loro uffici!).
Puoi facilmente fugare i dubbi sulla legittimita' dell'email scrivendo ad
hr o forse addirittura guardando sulle pagine dell'azienda.

Quello che e' e' hiring a strascico, che chiaramente e' una pratica del
cazzo. Pero' capiteli... il mercato interno di Dublino e' saturissimo e
spietato: hanno bisogno di prendere gente da fuori. I loro quartieri
generali sono a Berlino... e anche li non si scherza come competizione. Non
so se hanno altri uffici...
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Dimmi tre libri informatici che non si può non aver letto

[enrico franchi]

Interessante... la difficolta' e' capire cosa sia un "libro informatico".
Per dire, dei tre che menzioni due sono sostanzialmente libri in area
project management, uno e' un libro su best practice di coding (in salsa
java, ma relativamente generalizzabile).

Altre persone hanno inteso "informatico" in modo completamente diverso.

Per me? Allora, il problema piu' grosso e' se vogliamo un informatico punto
e basta, un ingegnere che lavora nell'industria, o chissa' cosa.

Io tendo a rispondere fra le prime due (quindi parlo di libri di interesse
per un ingegnere che fa l'ingegnere).

Per me i criteri di scelta sono:
1. ampia applicabilita': e.g., alcuni titoli menzionati sono eccezionali,
ma per dire... la maggior parte degli informatici potrebbe non avere mai
bisogno di leggere un libro sui compilatori... e perfino un libro sulle
reti -- come il Tanenbaum -- potrebbe essere un overkill). Come corollario,
non citero' libri specifici su un linguaggio o su una tecnologia: e' ok che
si parli di un linguaggio, ma l'idea e' che sia usato come strumento, non
come fine.
2. ampio spettro: voglio che il libro non copra una sola base... devo
sceglierne solo tre. Quindi per esempio un libro specifico sugli algoritmi,
per quanto utile, potrebbe bruciare uno dei tre preziosissimi slot senza
portare troppo valore aggiunto)
3. Non voglio vedere *nulla* sui design pattern che sono una delle piu'
grandi fregature che ci hanno propinato: invece di darci modelli con il
giusto livello di astrazione, ci danno la programmazione ad oggetti e poi
ci devono costruire sopra questo set di pattern che stanno solo dicendo:
quello che hai (OOP) non e' abbastanza espressiva, hai bisogno dei pattern
perche' ci sono schemi di problemi simili che possiamo astrarre. E allora
datemi un modello espressivo in primo luogo. E non e' nemmeno che la
programmazione ad oggetti non mi piace... semplicemente e' monca. Parliamo
di programmazione ad attori e restringiamo il campo di applicabilita' sul
componente invece che a livello di codice spiccio. Oppure prendiamo un
modello piu' semplice (la maggior parte dei pattern vanno a coppie: uno che
sfrutta composizione e uno che sfrutta ereditarieta'... a me indica
chiaramente un problema. e allora abbandoniamo il concetto di
ereditartieta' e un sacco di roba inutilmente complicata e fuorviante se ne
va...)



Quindi:

1. SICP: davvero. Se quando intervisto qualcuno conoscesse tutto e solo
quello che c'e' sul SICP, dal punto di vista tecnico lo prenderei al volo.
Se dovessi restringermi ad uno ed un solo libro, sarebbe questo. Ti insegna
a pensare funzionale *e* ad oggetti. Ti insegna a gestire lo stato.  Ti
fanno un po' di strutture dati (specialmente ti rende chiara la differenza
fra un tipo di dato astratto e un'implementazione). Ti fa vedere come si
scrive un'interprete (che e' un concetto molto generale), ti presenta il
modello di macchine a registri (che e' un modello utile per ragionare sul
codice), ti fa vedere come funziona un compilatore (appunto: un ingegnere
non deve per forza sapere scrivere un compilatore allo stato dell'arte --
dragon book --, ma deve avere idea di come funzioni). Ti spiega la
differenza fra eager e lazy evaluation, ti introduce alle magie della
metaprogrammazione e perfino della computazione non deterministica. E' di
fatto un concentrato di tutto quello che e' "CS fundamentals".

2. The Linux Programming Interface: vince per l'ampiezza dello spettro e di
applicabilita'. Al di la del nome, copre in modo eccellente POSIX e non
solo Linux. Certo... se sei MS sei un po' fuori, target. Ma per il resto...
Quel libro copre da solo sistemi operativi (praticamente tutto quello che
si vuole), un bel po' sulle architetture degli elaboratori *e* abbastanza
networking per il 90% delle esigenze. Incidentalmente, contiene anche best
practice preziosissime per C (e C non e' un linguaggio come tutti gli
altri: e' il linguaggio sul quale puoi costruire praticamente tutto il
resto.

3. Pragmatic Programmer: ti spiega come si "vive" nell'industria. Non mi
dilungo perche' vedo che e' ampiamente noto. Spiega un pochetto di come
gestirsi la carriera, un pochetto di agile, un pochetto di trucchi... un
sacco di roba preziosa. E' stato un libro che ho letto "tardi" (sebbene lo
avessi da tanto in libreria). Mi ha stupito perche' nel 1999 conteneva gia'
in nuce buona parte di quello che sarebbe successo nei 15 anni successivi.




2015-11-29 16:50 GMT+00:00 Marco Beri :

> Mi hanno fatto questa bella domanda e io ho risposto così:
>
> 1) Peopleware
> 2) Clean Code: A Handbook of Agile Software Craftsmanship
> 3) The Mythical Man-Month
>
> E voi? Cosa rispondereste?
>
> Ciao.
> Marco.
>
> --
> http://beri.it/ - Un blog
> http://beri.it/i-miei-libri/ - Qualche libro
> http://beri.it/articoli/ - Qualche articolo
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>


-- 
.
..: -enrico-

Re: [Python] [OT] unittest scritta in C

[enrico franchi]

2015-12-02 8:55 GMT+00:00 Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com>:

> Se vuoi degli utenti ti consiglio di mettere un README con un esempio ed
> un link alla documentazione buildata :)
>

+1

Il codice sembra molto pulito e mi e' piaciuto. Dopo di che senza
documentazione dovrei leggermi tutto quanto e non ne ho esattamente
voglia... ;)



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

Re: [Python] [OT] unittest scritta in C

[enrico franchi]

2015-12-02 17:18 GMT+00:00 Marco Giusti :

> Come no, hai pure risposto.
>
> http://lists.python.it/pipermail/python/2015-November/024839.html
>

Scusa, ma era un altro thread! E infatti non avevo capito manco il tuo
commento...


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

Re: [Python] Aiuto esercizio python

[enrico franchi]

2015-11-24 17:04 GMT+00:00 Enrico Bianchi :

> Cosa non c'e' chiaro in tutto cio'?
>>
> Che non c'e` il video su Youtube :)


Macche'... il video c'e'. Spiega questo e un paio di altre cose. Solo che
il video e' piuttosto oscuro.

https://www.youtube.com/watch?v=gjIibV7xG_0


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

Re: [Python] Digest di Python, Volume 117, Numero 23

[enrico franchi]

2015-11-24 17:22 GMT+00:00 Daniele Zambelli :

> Il 24 novembre 2015 17:06, Marco Beri  ha scritto:
> > Io non lo trovo poi così ricorsivo. Lo trovo "indentato". Questo sì...
> :-)
>
> Penso che la ricorsività  venga dal fatto che children referenzia
> liste di elmenti di tipo d.
>

+1

Un albero e' "ricorsivo" nel senso che la definizione di albero e'
ricorsiva. Proprio del concetto di albero.

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

Re: [Python] Aiuto esercizio python

[enrico franchi]

2015-11-23 18:33 GMT+00:00 Gianluca Amato :

> Questo è il pezzo che non capisco.. "Un dizionario d rappresenta un albero
> se d ha due chiavi: 'name' con
> valore il nome di un nodo e 'children' con valore la lista (eventualmente
> vuota)
> dei nodi figli e quest'ultimi sono a loro volta dizionari dello stesso
> tipo. Si
> veda l'esempio qui sotto.
> Implementare inoltre la funzione create_tree(d) che preso un dizionario d
> che
> rappresenta un albero crea il corrispondente albero con nodi di tipo TNode
> e ne
> ritorna la radice. La funzione deve aggiungere i figli nello stesso ordine
> in cui
> sono elencati nelle liste delle chiavi 'children’.” Come lo costruisco
> l’albero? Grazie in anticipo
>
>
Questo stesso esercizio lo ha postato qualuno, forse tu stesso, sul forum
di Python-it.

Python (l'utente, non il linguaggio) ha risposto (e si applica anche in
questo caso):

Il dizionario non lo devi creare, ti viene dato. Devi scrivere una funzione
che prenda in ingresso un dizionario formato in quel modo e restituisca un
oggetto TNode (di cui presumibilmente dovrai scrivere la classe) che
rappresenta la radice. Ovviamente dovrà essere possibile attraversare
l'albero partendo dalla radice, quindi dovrai aggiungere tutti i figli
mentre attraversi il dizionario.

Nota: se non sai cosa significhi un termine, basta cercare. Ad oggi, Google
è ancora gratis. Ma poi anche un minimo di ragionamento: cross|posting,
cosa sarà mai?


Cosa non c'e' chiaro in tutto cio'? E' un esercizio *veramente* banale.
Basta fermarsi a riflettere.

1. sai creare una classe (immagino di si, se non te lo avrebbero dato)
2. sai creare un oggetto (come sopra)
3. sai creare una funzione (come sopra)
4. Se il dizionario di partenza contiene due campi, name & children...
secondo te, che faccia deve avere un oggetto che rappresenta la stessa
roba? Tipo... quali attributi ti aspetti che abbia?
5. Mettendo insieme 1, 2 e 4 vuole dire che puoi tirare fuori
un'implementazione iniziale di TNode (verosimilmente, sono 4 righe per la
cosa piu' semplice che funziona).
6. Questo e' l'esempio piu' semplice in assoluto di ricorsione. Devi solo
chiederti quale sia il caso base... ma pensa, e' talmente semplice in
questo caso che semplicemente se scrivi il codice nel modo piu' naturale
possibile il caso base viene automaticamente supportato.
7. Con 3 e 5 e 6 puoi scrivere la funzione (che sara' probabilmente lunga
tipo 4-5 righe).


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

Re: [Python] Digest di Python, Volume 117, Numero 22

[enrico franchi]

2015-11-24 14:45 GMT+00:00 Edoardo Gabrielli :

> In sua difesa dico che il problema è veramente difficile per i nostri
> livelli.
> Purtroppo corrono veramente tanto al nostro corso.
>

Dici che corrono? A me sembra un problema assolutamente adeguato dopo circa
2 mesi di corso, potenzialmente sul lato semplice. *Specie* perche'
lavorate in Python. Fosse stato C++, un paio di problemi in piu' ci
sarebbero stati.

In generale, tutte le volte che ho avuto l'impressione che un corso fosse
troppo difficile, e' semplicemente saltato fuori in retrospettiva che non
stavo facendo abbastanza esercizi. E programmare e' una cosa che si impara
ad esercizi; punto e fine.

Se questo esercizio e' troppo complicato allo stato attuale, vuole dire
semplicemente che bisogna fare piu' esercizi (piu' semplici).  Comunque
nell'altro post (se poi usaste la ml come tutti non ci sarebbero thread
spezzati, quote dal digest e chi piu' ne ha piu' ne metta) vi ho fatto la
scomposizione del problema. Mi aspetto che l'unico pezzo in cui ci possa
essere poca chiarezza e' il punto sulla ricorsione.

Come si capisce la ricorsione? Capendo la ricorsione (pun intended & old).
Scherzi a parte... facendo esercizi (piu' semplici) sulla ricorsione.

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

Re: [Python] Si può imparare

[enrico franchi]

2015-11-24 9:45 GMT+00:00 giulianc51 :

> acc, che brutta reputazione ti sei fatto in questa lista,
>

*Ottima* reputazione, dal mio punto di vista. Finestre rotte. Se lasciamo
una finestra rotta, presto tutto l'edificio avra' le finestre rotte.
Bisogna tenere pulito. ;)


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

Re: [Python] Digest di Python, Volume 117, Numero 23

[enrico franchi]

2015-11-24 15:28 GMT+00:00 Edoardo Gabrielli :

> Concettualmente è chiara, il fatto che è un dizionario di liste di
> dizionari è complesso.
>

L'unico modo per passare da "concettualmente chiara" a "chiara" (ovvero
"strumento nel mio arsenale che so usare") e' solo esercizio.


> Comunque magari vi posto il mio codice se ho qualche problema (l’ho
> iniziato da poco).
>

Questa e' un'ottima idea. Vedrai che la soluzione e' in effetti piu' facile
di quello che ti aspetti.


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

Re: [Python] Pordenone

[enrico franchi]

2015-11-20 10:29 GMT+00:00 Valerio Maggio :

> Si fa quel che si puo'... le battute pragmatiche sono un classico
> difficile da resistere.
> Davvero... specie perche' qui non le capiscono…
>
>
> Dove per "qui", immagino tu intendessi dire "nel posto dove ti trovi".. no
> "qui" in mailing list…  :D
>

Chiaramente! Qua, in Irlanda, o per lo meno a Dublino, e' un tipo di
umorismo che non attacca.
Qui preferiscono battute tipo: "ci sono un francese, un tedesco e un
inglese in un bar. L'inglese muore d'infarto fra atroci sofferenze."

;)

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

Re: [Python] Pordenone

[enrico franchi]

On Fri, Nov 20, 2015 at 8:59 AM, Carlo Miron  wrote:

> > Ho cercato su Wikipedia per dare la stessa risposta ma poi mi sono detto
> "Marco, non fare il solito cazzone".
>
> Per Fortuna che c'è Rik0™.


Si fa quel che si puo'... le battute pragmatiche sono un classico difficile
da resistere.
Davvero... specie perche' qui non le capiscono...


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

Re: [Python] Pordenone

[enrico franchi]

2015-11-19 17:32 GMT+00:00 piergiorgio pancino :

> c'è nessuno che abita in zona Pordenone?
>

circa 50 mila persone in citta', 300 mila nella provincia.


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

Re: [Python] Rappresentazione di timedelta. Era: Re: Operazioni sul tempo.

[enrico franchi]

2015-11-06 13:01 GMT+00:00 Gabriele Battaglia :

> E se sovrascrivessi il metodo __str__ di datetime.timedelta? Sarebbe
> possibile, e come?
>

Pessima pessima pessima idea.

Primo hit di google:
http://stackoverflow.com/questions/538666/python-format-timedelta-to-string


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

Re: [Python] Progetto SW

[enrico franchi]

2015-11-06 17:16 GMT+00:00 Enrico Bianchi :

>
> Grosse feature mancanti a PostgreSQL sono ad esempio il mancato supporto
> al clustering (cosa che con PostgreSQL-XL stanno risolvendo che, se non ho
> capito male, finira` dentro a 9.5),

parallel query (che risolvi pero` con pgpool-II), partizionamento e
> sharding nativi.

In teoria sono tutte cose che hai anche con componenti esterni (come ho
> riportato), ma significa comunque che devi aggiungere pezzi di
> infrastruttura non indifferenti. Oracle invece da questo punto di vista fa
> tutto internamente (se paghi).


Il problema e' sempre capire cosa serve, cosa non serve e se una cosa che
serve e' implementata in modo che funziona.
Tutte queste features auto-magiche, per intenderci, sono molto fiche ... ma
poi bisogna capire se funzionano decentemente.

Che so... verrebbe da dire un po' delle "nuove" feature che hanno aggiunte
a Cassandra (per questioni di marketing) che pero' nella pratica hanno una
lista di gotcha non indifferenti e sono anche un ottimo modo per inchiodare
un cluster cassandra come performance.

Altri aggeggi (che so, il clustering) richiedono comunque parecchia
infrastruttura. Che sia o meno multi-vendor (ovvero, che sia piu' integrato
in Oracle, ok... ma se vuoi un cluster hai comunque bisogno di tirare su
nodi, lb, possibilmente qualche sorta di controller).

Poi, su una nota completamente differente, mi viene sempre da dire... ma
*veramente* vogliamo queste cose in un db relazionale? Spiego meglio...
molte delle feature che menzioni (sharding e partizionamento) non sono per
nulla banali da risolvere in modo efficiente in modo generale. Non a caso,
in generale, i sistemi che sono migliori da questo punto di vista offrono
un modello piu' debole e piatto di quello relazionale. E saltano dentro i
sistemi distribuiti con tutti i loro problemi, CAP e tanti saluti.

Quindi se il mio db offre queste feature, ottimo, eh. Ma se poi devo
comunque mettermi a pensare le query in modo diverso che tengono conto di
come sono messe le cose, altrimenti mi parte completamente la
performance... e quindi magari mi metto a progettare lo schema in modo da
supportare meglio il tutto, etc etc etc. E poi alla fine mi trovo con
qualcosa che e' piu' vicino a Cassandra che a uno schema relazionale fatto
come si deve...

Perche' il brutto di sta roba e' che veramente non ci sono pasti gratis. Se
hai un sistema con update, il CAP e' veramente doloroso. E non puoi
uscirne. Se hai un sistema incrementale, molti aspetti sono piu' leggeri.
Ma un RDBMS *deve* offrirmi il modello relazionale, che contiene update.
Quindi certo, avro' un layer inferiore che probabilmente cerca di lavorare
append only e poi lo cerco di esporre in modo relazionale. Etc etc etc.

Quindi: sta roba... l'hai provata *davvero*? Perche' se c'e', ma di fatto
va usata con molta cura, non sono convinto che non mi convenga usare Dynamo
o mettere su un cluster cassandra o hadoop.

Io capisco che tutti i provider di sistemi implementano cose nel tentativo
di vendere il sistema "per ogni utilizzo". Ma noi come utenti dei sistemi
sappiamo benissimo che in generale sono palle: sistemi diversi ffunzionano
bene per use case diversi.



> Poi ovviamente ci sono cose che PostgreSQL fa meglio (e.g. PostGIS vs
> Oracle Spatial), ma Oracle rimane comunque un punto di riferimento
>
> Si, con Oracle hai il supporto del vendor (piuttosto caro) e hai molti dba
>> certificati.
>>
> Il supporto a PostgreSQL lo hai per mezzo di 2ndQuadrant (i piu` famosi)


Come dicevo nel mio messaggio, ci sono una serie di compagnie (fra cui 2nd
Quadrant, che io pero' non avevo menzionato) che lo fanno.


> Non sono a conoscenza di come Oracle se la cavi a risolvere i problemi che
>> su PG risolverei le cose che farei con jsonb.
>>
> Oracle 12c implementa il supporto a JSON sia come data type, sia come
> funzioni per la gestione e manipolazione (non so dirti di piu` pero`)
>
>
Ok. Perche' PG fa un bel po' di roba "unica" su tutto questo. Roba anche
*preziosa* per cui mi viene voglia di non considerare soluzioni NoSQL per
tanto e' fatta bene. Se si tratta solo di avere json sintatticamente
corretto con qualche forma di ricerca limitata e lenta (come per esempio
era nelle versioni piu' vecchie di postgresql) la cosa mi interessa di
meno.


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

Re: [Python] Progetto SW

[enrico franchi]

2015-11-04 16:31 GMT+00:00 Enrico Bianchi :

> Però sì, non c'è SQL migliore di PostgreSQL (che io sappia).
>>
> Oracle :P


Come dire... obietto. Anche perche' "migliore" e' un termine relativo.

Trovo che in PG the autovacuum possa essere un dito al culo (ho visto dare
fastidio...).
Non ho trovato grosse features mancanti in PG, d'altra parte.

Si, con Oracle hai il supporto del vendor (piuttosto caro) e hai molti dba
certificati.
Sono convinto che oggigiorno anche trovare DBA postgre non sia un problema
enorme (non solo, e' piu' facile trovare sistemisti/sviluppatori che
comunque hanno una buona conoscenza della piattaforma, tanto da rendere un
DBA specializzato forse non completamente necessario). E ci sono tante
compagnie che offrono supporto di qualita' su PG. Confrontare la qualita'
del supporto, chiaramente non sono in grado (non avendo usufruito di
nessuno dei due).

Non sono a conoscenza di come Oracle se la cavi a risolvere i problemi che
su PG risolverei le cose che farei con jsonb.


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

Re: [Python] Operazioni sul tempo.

[enrico franchi]

2015-11-05 11:05 GMT+00:00 Gabriele Battaglia :

> Perché esistono entrambi e quali differenze sostanziali hanno?
>

Tipo che uno gestisce una data *e* un ora e l'altro solo un'ora [ora come
orario, non come ora?
E, addirittura, c'e' anche un tipo che gestisce *solo* una data.

Un'estensione molto comoda della stdlib (che per certe operazioni e'
veramente scomoda) si trova qui: https://labix.org/python-dateutil

E' una di quelle librerie che probabilmente vuoi usare tutte le volte che
devi fare qualcosa di non interamente banale con date e ore.

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

Re: [Python] pytest e classi

[enrico franchi]

2015-10-28 11:38 GMT+00:00 Manlio Perillo :

>
> > Eh... come dicevo, fanno tutti cosi', e' sensato farlo anche solo per
> > semplificare il ragionamento ai tuoi utenti.
> > Sebbene, a mio avviso, ancora una volta Go rompe gli schemi per fare la
> cosa
> > giusta.
> >
>
> Go può farlo perchè è safe rispetto a C.
> In C se vuoi continuare dovresti gestire SIGSEV, cosa non banale e non
> portabile.
>

Si, ok, ci sono un po' di cose diverse, ma non direi che quello e' il
problema.

Spiego meglio: in C potresti fare una suite di test che invece che usare
una qualche funzione "assertOk" che ti vola fuori dalla funzione chiamante
in caso di problemi (ovviamente tutto bello integrato con la libreria di
testing) utilizza una funzione "error" analoga alla funzione omonima di Go.

Detto questo, devi *comunque* gestire SIGSEV, perche' al di la di tutto uno
puo' sempre avere un baco nel codice che scoppia con SIGSEV e quello che
vorresti e' che il processo che sta facendo girare i test non muoia
immediatamente ma esegua gli altri test. Il che e' chiaramente un problema
non da poco, visto che SUSv3 ti dice chiaro e tondo che i seguenti
comportamenti sono undefined behavior:
1. ritornare dal sig handler
2. bloccarlo
3. ignorarlo

Per cui di fatto l'unica cosa che potresti fare e' pulire quello che devi
pulire, eventualmente salvare un po' di stato da qualche parte (che so...
statistiche per il test runner o qualunque cosa) e poi comunque uscire.

Quindi credo di avere capito quello che intendevi... ma non credo sia un
problema. Nel senso che per come funziona C, di fatto, devi eseguire i vari
test in processi separati (perche' troppe cose possono mandare in undefined
behavior il tutto, quindi non puoi avere un singolo processo che esegue
tutti i test). Detto questo puoi offrire Error con la semantica di Go. Se
poi per qualunque motivo devi abortire (SIGSEV e' solo uno dei casi),
vorra' dire che il gestore di test scoprira' che quello specifico test e'
fallito [e potenzialmente avra' qualche informazione aggiuntiva]. Mi
verrebbe anche da dire che se vuoi usare  ptrace (e probabilmente lo vuoi
fare) ti da anche una struttura molto piu' logica.



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

Re: [Python] pytest e classi

[enrico franchi]

2015-10-27 19:29 GMT+00:00 Manlio Perillo <manlio.peri...@gmail.com>:

> 2015-10-27 15:51 GMT+01:00 enrico franchi <enrico.fran...@gmail.com>:
> > [...]
> >> La libreria standard di Go usa questo metodo, ed in effetti può essere
> >> visto come un problema.
> >
> >
> > In realta' non lo e'. Il punto e' che tutto questo discorso dei test e'
> nato
> > attorno ad una primitiva come assert che quando hai un problema
> > essenzialmente interrompe l'esecuzione li (tipicamente tirando
> un'eccezione)
> > e quindi le asserzioni successive non vengono eseguite.
> >
>
> Questo comportamento non è del tutto irragionevole.
>

No, non e' interamente irragionevole. Ma io credo che sia nato attorno al
fatto che esisteva assert, piuttosto che attorno al fatto che era la
semantica giusta.

Considera un test case in cui devo testare che un array non sia NULL e
> che contenga una serie di caratteri.
> Se il test assert p != NULL fallisce, il test case *deve* essere terminato.
>

Si. E viceversa se hai un oggetto di cui vuoi testare piu' proprieta' (cosa
di per se lecita: stai semplicemente controllando lo stato di *un* singolo
oggetto che e' l'output del SUT e semplicemente lo stato e' accessibile
tramite piu' proprieta') la cosa diventa scomoda. Diventa scomoda anche in
presenza dei "parametrized tests".

Entrambi gli approcci hanno vantaggi e svantaggi. A mio avviso la semantica
che non lancia l'eccezione e' complessivamente piu' flessibile (ovvero e'
meno pesante modellare la semantica in cui fermi il test sulla base di una
primitiva che di per se non lo ferma rispetto che il viceversa).

Non a caso in Go hai anche FailNow/Fatal* che hanno il comportamento di
fermare il test. Per cui semplicemente scrivi la cosa piu' coincisa
possibile a seconda di quello che vuoi fare.

Tempo fa avevo sviluppato una libreria per l'unit testing in C (oddio,
> quanto codice ho che non ho mai publicato...).
> La libreria usa il protocollo TAP, eppure avevo deciso di interrompere
> l'esecuzione della funzione di test
> in caso di fallimento, anche se non necessario (usando longjmp),
> perchè mi sembrava la scelta più ragionevole.
>

Eh... come dicevo, fanno tutti cosi', e' sensato farlo anche solo per
semplificare il ragionamento ai tuoi utenti.
Sebbene, a mio avviso, ancora una volta Go rompe gli schemi per fare la
cosa giusta.


>
> Non so perchè ero convinto che il test fosse interrotto in caso di
> fallimento, anche se la documentazione
> è chiara.
>
>
Ci sono anche funzioni che ti danno questa semantica. Semplicemente scegli
quello che ti serve.
Magari eri abituato ad usare quelle e non ti eri guardato quelle altre.


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