[Python] idio[ma]ticità

[Marco De Paoli]

Il giorno 22 aprile 2015 18:58, enrico franchi <enrico.franchi a gmail.com>
ha scritto:

> l'ultimo in ordine di tempo mi è successo con djangorestframework: in base
>> ad un parametro many=True mi istanziava "a mia insaputa" una classe wrapper
>> che conteneva la mia
>> Questo significava che non avevo alcun modo semplice per fare
>> l'override/plug
>> Insomma, mi sono convinto che il principio stesso che "può succedere di
>> chiamare il costruttore di una classe ma qualcuno (presumibilmente per il
>> tuo bene) decide di restituirtene un altra", beh, non mi piace granchè
>>
>
> Ma non e' che tu parli semplicemente di definire __new__? Per quello io ho
> diversi use-case interessante.
>

cavolo, hai ragione, bastava __new__
ora, calma, aspetta un momento, io ricordo distintamente che usavano una
metaclasse ...
o io ho citato a casaccio oppure loro facevano un overkill

in realtà ricordo solo che volevo uscirne il prima possibile perchè mi ci
ero imbattuto solo per riuscire a far andare come volevo io le browsable
api in un caso particolare
insomma, come dire che mi trovavo con il motore a posto e stavo perdendo
tempo sul tappino degli pneumatici
ricordo vagamente di aver dato qualche martellata e aver fissato in qualche
modo quel disgraziato di tappino
e centrava una metaclasse, giuro

se posso domani ci guardo


>
>> In questi casi tendo ad usare una funzione che faccia da Factory
>> Sarò pure meno cool, ma preferisco essere più esplicito e comprensibile
>>
>
> Il problema e' che c'e' sempre prima o poi il pistola che non la chiama e
> fa a mano. Statistico. E la volta che succede e la cr non passa per le mie
> mani... Il che vuole dire che se e' un nice to have, va bene. Se
> instanziare direttamente rompe la semantica della classe, niente, vai di
> __new__, mi prendo lo sbattimento io, ma almeno non verro' svegliato alle
> quattro di notte.
>
> Si, ok... potrei sempre avere la famosa _Classe. In questi casi di solito
> basta.
>
>>
>> Al momento non alcun motivo valido per scomodare Tornado nei miei
>> progetti: Django con i worker uWSGI mi vanno benissimo
>>
>
> A me Django sta molto stretto. Non amo particolarmente il fatto che se
> devo fare qualche API call dentro Django rischia di andare in timeout il
> tutto.
>

api http, intendi? ok, capisco
l'altro timeout sarebbe il caso di client websockets o comet o roba
simile...

beh, certo, in particolare per il secondo caso django non reggerebbe


> Si, certo... dovrei spostare tutta sta roba in Javascript e tanti saluti.
>

ok, lasciamo perdere le websockets per il momento, ma se hai solo il
problema di operazioni potenzialmente lunghe (es. le api che si diceva)
allora perchè Javascript? basta delegare ad una batteria di processi di
backend
un po' di risorse in più e passa la paura
... oddio, poi cosa si intenda con "un po' di risorse in più" dipende dalla
scala del problema!
(ogni riferimento al committente di qualcuno di noi è puramente causale :-)
)

ok, introducendo i back-end, l'architettura si incasina: no doubt

ci vorranno come minimo...
coda (redis?) per passaggio parametri fra front-end e backend, supervisor
dei backend (dovrai pur monitorare lo stato dei processi), staging area per
i risultati (su db, ehm, dipende...), notifiche differite all'utente,
gestione delle transazioni db e gestione delle eccezioni (già, perchè se
qualcosa va storto qualcuno presumibilmente lo deve venire a sapere, e
magari senza necessariamente doversi tenere davanti il tail -f di un log
del server)

insomma, ti tieni il buon vecchio sequenziale ma il tuo bel flusso
request/response http e ormai poco più che un "vissero felici e contenti"
quando ormai le fiabe sei tu a leggerle ad altri

ma so che sto dicendo cose note, diciamo che me le ripeto per convincermi
che sto facendo la scelta giusta

la mia situazione è che, sebbene continui ad essere alla ricerca dell'
"architettura di backend pulita definitiva" e non sia riuscito a trovarla,
tuttavia l'asincrono (o event driven o callback che dir si voglia) sono
riuscito totalmente ad evitarlo


>
>> Diciamo che ho risentito parlare di Tornado con asyncio e la prima
>> domanda da nerd è "datemi un occasione per giocarci, se non me la date me
>> la invento!"
>>
>
> Caruccio, si. Poi detto fra noi... Asyncio non e' che mi abbia colpito
> troppo.
>

ah, si? cosa non ti convince?

per quanto mi riguarda io ho perso un po' il treno (per mia fortuna, credo)
di dovermi scontrare con gevent, callback, greenlet, stackless-python,
twisted e compagnia cantante
mi aveva pigliato molto erlang ma alla fine non ho avuto bisogno neanche di
quello

per cui a questo punto spero che asyncio sia il "preferably one and only
one method" che dovrò veramente studiarmi

arriva un po' tardi? forse

beh, io lo spero che sia "one and only one"
e se lo fosse, beh... meglio tardi che mai


>
>> 5. etc. etc. etc.
>>
> In Python 3 puoi scrivere ...
> E' sintassi valida.
>
>>
>> uhm, questa temo di non averla capita ...
>>
>
> Eh, non ho un python 3 per fare lo snob.
> Essenzialmente ... e' sintassi valida di Python 3. Presente quando si
> scrive
>
> class Foo(Bar):
>     ...
>
> per intendere che poi ci metti quello che ti pare? Ecco, e' Python 3
> valido.
>

ma dai!
non si finisce mai di imparare

per dirlo in modo idiomatico (delle mia parti)
Ogni mês si fâs la lune, ogni dì s'impare une


ma dato che i miei progetti sono soprattutto DB-bound (si può dire?)
>> guadagnare sul CPU-time lato pure-python sarebbe più o meno inifluente
>>
>
> 1. mi piace un sacco la definizione db-bound. Proprio perche' in effetti,
> in linguaggi come Python la differenza di performance fra db e python e'
> talmente tanta che roba che logicamente dovrebbe essere I/O bound in
> effetti potrebbe essere CPU bound. No shit.
> 2. Quindi no, altro che ininfluente. Io mi aspetto che le cose migliorino
> parecchio.
>
> Se il tuo db e' veloce e la tua query e' scritta bene, c'e' proprio il
> caso che il collo di bottiglia sia il python che ti porta i risultati nel
> mondo Python. E potrebbe anche essere piu' vero se hai un ORM che ti crea
> oggetti complessi (ma non ho dati su questo).
>
> Poi con gli ORM e' difficile da dire: magari sotto sta facendo tante di
> quelle query insensate che il db non puo' fare miracoli.
>

io ho in realtà un approccio di ottimizzazione piuttosto banale che seguo
spesso
vado effettivamente lento? misurare, misurare, misurare, Ora e ad ogni
passo successivo
ok, eliminiamo le cause più stupide (es. manca un indice)
non basta? andiamo a vedere quante "query insensate" sta facendo l'orm, e
spalmiano un po' di hint (select_related, values, iterator, etc.)
non basta? sql-diretto, mi riscrivo io la query sql. Punto (in realtà
"punto" un cavolo, perchè, mannaggia, va a finire che mi devo
reimplementare una parte della logica applicativa di aggregazione
scrivendola in sql)

poi, per carità, qui io l'ho fatta lineare mentre in realtà ad ogni passo
mi chiedo se avrebbe senso usare memcache per qualcosa, oppure se lo schema
dei dati è fallato perchè eccessivamente normalizzato (o stupidamente
denormalizzato), poi ci sono anche frequenti casi in cui mi chiedo se ho
sbagliato lavoro

ma va beh, alla fine della fiera mi ritrovo con una bella query che... mi
fa aspettare

... e sono al db-bound come lo intendevo io: python ormai l'ho scarnificato
e pesa poco, e mi ritrovo che il mio worker tende ad aspettare il db
se i tempi ottenuti sono sufficienti, bene, altrimenti si inizia a scavare
sotto il fondo del barile del mio applicativo e si finisce su partitioning
/ materialized-views e altre amenità del db

se invece i tempi restano lunghi allora, ammesso sia accettabile per
l'utente (più spesso di quanto si creda, in realtà. E io tendo a remare
molto in questa direzione) allora risposta differita e via pedalare:
l'utente mi mette i criteri e poi l'elaborazione gli arriva in un bel xlsx
(tanto per recuperare il contesto dell'op question) da scaricare tramite
apposita pagina del sito

M.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150422/5d418eed/attachment-0001.html>