Re: [Python] Pettegolezzi su Python

[enrico franchi]

2015-04-20 22:09 GMT+02:00 Enrico Bianchi :

> In questo si, ovvero viene fatto un abuso di type(),


Esatto. Quel codice non va bene poiche' restringe l'input in modo
insensato. Potrebbe funzionare con ben altri input e li sto tagliando fuori
senza motivo.

Ora, riguarda quello iniziale:

def add(x : int, y : int) ...

Vedi che ha lo stesso problema logico? Ovvero, se per qualunque scopo venga
usato (documentazione, static analysis, etc) "mente".  Quello che
probabilmente avresti voluto, sarebbe stato *almeno* annotare con Number.


> senza contare il raise buttato li senza motivo


Il motivo c'e': qualcosa devo fare se decido che gli argomenti non mi vanno
bene.


> (ovvero, avrei almeno messo un else per rendere piu` sensato quel codice)


L'else in questo caso e' purissima questione stilistica (nel senso che
semanticamente non cambia nulla); diciamo che non e' quello il punto, come
non e' il punto che il type error non abbia un messaggio d'errore sensato,
etc etc etc.


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

Re: [Python] Proposta di collaborazione

[Enrico Bianchi]

On 04/20/2015 12:11 PM, Roberto Polli wrote:

Mi spiegate perchè mysql fa schifo, però?
A me basta la gestione delle utenze e dei permessi per farmi inorridire 
(di peggio ho trovato solo la gestione delle utenze di MongoDB) :)


Enrico
P.S. oddio, non e` che gli altri database siano messi meglio (PostgreSQL 
compreso), ma le ritengo comunque piu` sensate...

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

Re: [Python] MySQL vs PgSQL: ne resterà solo uno! Re: Proposta di collaborazione

[Enrico Bianchi]

On 04/20/2015 12:54 PM, Roberto Polli wrote:

quali sono le esperienze personali (in lista) in base a cui uno
sceglie A vs B piuttostoché dice
A è ciarpame, B è fighissimo.

Per esperienza personale, scelgo:

 - PostgreSQL quando devo fare qualcosa di grosso
 - Firebird quando devo fare qualcosa di piccolo
 - SQLite quando devo fare qualcosa di piccolissimo
 - Un qualsiasi altro database quando mi e` imposto da un cliente ;)

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

Re: [Python] MySQL vs PgSQL: ne resterà solo uno! Re: Proposta di collaborazione

[Roberto Polli]

On 04/20/2015 12:11 PM, Roberto Polli wrote:
>>Mi spiegate perchè mysql fa schifo, però?
>A me basta la gestione delle utenze e dei permessi per farmi inorridire (di 
>peggio ho trovato solo la gestione delle >utenze di MongoDB) :)

Esempio pls?

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

Re: [Python] MySQL vs PgSQL: ne resterà solo uno! Re: Proposta di collaborazione

[Enrico Bianchi]

On 04/20/2015 04:00 PM, Roberto Polli wrote:
Come vengono indicizzati i campi json? 

CREATE INDEX indice_json ON tabella_con_json((campo_json->>'chiave'));

A tal proposito, ricordo sempre con piacere un test fatto su di una 
collezione esportata da MongoDB di 13 milioni di record che sul database 
NoSQL inchiodava una macchina con 64Gb di RAM mentre su PostgreSQL, dopo 
essere stata indicizzata, girava nei tempi del mezzo secondo su di un HP 
MicroServer N54L con 2Gb di RAM



tipo?
Penso che intenda tutti i risultati che vengono restituiti quando 
SQL_MODE e` differente da STRICT_ALL_TABLES (che non e` il default)


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

Re: [Python] idio[ma]ticità

[Marco De Paoli]

ciao Enrico,
grazie delle risposte

in realtà volevo fare alcuni esempi random su tecniche un po' esoteriche
rispetto al mio operare corrente
nel mio lavoro di ogni giorno cerco di mantenermi molto KISS
poi arrivano i talk di pycon, ti aprono un po' le vedute e finisci a volte
per riconsiderare pattern o tecnologie che normalmente lascierei un po' nel
cassetto o in backlog



Il giorno 20 aprile 2015 18:56, enrico franchi 
ha scritto:

>
> 2015-04-20 14:50 GMT+01:00 Marco De Paoli :
>
>> 1. potrei farlo con una meta classe
>>
>
> Pessima idea. Ci sono casi in cui le meta-classi sono il sistema piu'
> rapido e robusto per avere una certa cosa. In generale sono un overkill. In
> generale, non sono la soluzione giusta.
>

concordo, nei casi in cui ho visto usare una metaclasse la soluzione
adottata non mi è piaciuta molto
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è
In questi casi tendo ad usare una funzione che faccia da Factory
Sarò pure meno cool, ma preferisco essere più esplicito e comprensibile


>
> 2. potrei inserire un server tornado giusto "per non si sa mai"
>>
>
> Non lo farei. Uno strato di architettura "per non si sa mai" e' comunque
> uno strato di architettura che si puo' rompere domani prima di avere
> provveduto ad un qualunque beneficio per il customer.
>

Sì, perfettamente daccordo. Il "per non si sa mai" era una battuta
Al momento non alcun motivo valido per scomodare Tornado nei miei progetti:
Django con i worker uWSGI mi vanno benissimo
Non uso websockets o roba simile per cui sopravvivo benissimo
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!"
Poi però mi sono calmato e sono tornato ad occuparmi di importazioni di
file Excel ;-)


>
>> 4. dovrei usare pytest e rifattorizzare tutti i setUp/tearDown del mio
>> progetto
>>
>
> Questa invece e' una buona idea. Cioe'... rifattorizzare tutto non
> necessariamente lo e'. Ma cominciare ad usare PyTest lo e'.
>

Il talk di Simone Dalla mi ha in effetti convinto a provarlo il prima
possibile


> Tipo una volta mi venne la balzana idea di convertire tutta una test-suite
> da nose a py.test; ora, i test vennero meglio, piu' chiari piu' robusti. Ci
> persi un monte di tempo. Adesso quando devo lavorare ad un progetto con
> test nose (o unittest) la mia policy e':
>
> 1. continuo a scrivere nose(unittest) finche' non ho un buon motivo
> 2. scrivo la parte con il buon motivo con py.test
> 3. a tempo morto riguardo i test, butto nel cesso i test vecchi e poco
> significativi (cosa che fa bene comunque), cerco di individuare dei pattern
> che beneficiano davvero di py.test e riscrivo quelli, un po' per volta.
> 4. ogni volta che tocco qualche test specifico, lo riscrivo con py.test
> (ma solo dopo che il procedimento di introduzione di py.test e' iniziato,
> motivato da una necessita' oggettiva).
>

Il mio piano che avevo in mente è più o meno simile. Tenendo conto delle
retrocompatibilità di py.test rispetto a unitest dovrei riuscire ad
introdurlo in modo abbastanza indolore e poi migrare un po' alla volta,
dove mi serve, usando fixture al posto di setUp/tearDown
Rifattorizzare di botto tutti i setUp/tearDown dei miei progetti sarebbe
invece, nel mio caso, un esagerazione


>
>> 5. etc. etc. etc.
>>
> In Python 3 puoi scrivere ...
> E' sintassi valida.
>

uhm, questa temo di non averla capita ...


>
>> 6. ah, già, anche... dovrei dare un occhiata al progetto pypy
>>
>
> Ottima idea.
>

già, indubbiamente, me lo dico da tempo
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
Ma vedi sopra per il ... "datemi un occasione per giocarci" :-)

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

Re: [Python] MySQL vs PgSQL: ne resterà solo uno! Re: Proposta di collaborazione

[Enrico Bianchi]

On 04/21/2015 11:04 AM, Roberto Polli wrote:

Esempio pls?
L'esempio e` il solito, ovvero per creare un'utenza praticamente devo 
confermare il fatto che esso sia creato, ovvero devo lanciare il comando 
FLUSH PRIVILEGES. Sugli altri database, un CREATE USER e` un comando 
finito, ovvero una volta creato non devo fare altro


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

Re: [Python] MySQL vs PgSQL: ne resterà solo uno! Re: Proposta di collaborazione

[Massimiliano Pippi]

2015-04-21 11:12 GMT+02:00 Enrico Bianchi :
> On 04/21/2015 11:04 AM, Roberto Polli wrote:
>>
>> Esempio pls?
>
> L'esempio e` il solito, ovvero per creare un'utenza praticamente devo
> confermare il fatto che esso sia creato, ovvero devo lanciare il comando
> FLUSH PRIVILEGES. Sugli altri database, un CREATE USER e` un comando finito,
> ovvero una volta creato non devo fare altro
>
No, sul serio, che problema c'è con il sistema di permessi di MySQL?

-- 
M.

@maxpippi :: http://dev.pippi.im/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] MySQL vs PgSQL: ne resterà solo uno! Re: Proposta di collaborazione

[Carlos Catucci]

2015-04-21 11:12 GMT+02:00 Enrico Bianchi :

> L'esempio e` il solito, ovvero per creare un'utenza praticamente devo
> confermare il fatto che esso sia creato, ovvero devo lanciare il comando
> FLUSH PRIVILEGES. Sugli altri database, un CREATE USER e` un comando
> finito, ovvero una volta creato non devo fare altro


Beh la cosa potrebbe essere una specie di "misura di sicurezza". Inutile
peraltro (per esperienza la terza volta che un programma chiede conferma
l'utente risponde si anche se c'e' scritto che si predne un calcio nella
prti basse).

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

Re: [Python] idio[ma]ticità

[Marco De Paoli]

Il giorno 20 aprile 2015 17:44, Massimiliano della Rovere <
massimiliano.dellarov...@gmail.com> ha scritto:

> Ma allora non ti conviene ciclare solo sulle colonne presenti in CN
> (avendo cura di inserire in CN tutte quelle che ti servono) ?
>

le colonne da "incrociare" sono infatti: quelle di CN, quelle dell'header
del xlsx, quelle che trovo nelle righe
e il giro, alla fine della fiera, è semplicissimo

1. processo la cella D13
2. ok, cosa mi dice l'header della colonna "D" ? "CODICE ARTICOLO"
3. ok, cosa mi dice il dic di rimappatura CN per il nome "CODICE ARTICOLO"?
"article_id"

ok, allora il valore della cella D13 lo devo mettere nel campo "article_id"

tutto qui
cercavo il modo più idiomatico per scrivere questa semplicissima "doppia
indirezione"


grazie a tutti per i vostri interventi,
Marco

P.S. ... se posso posto lo snippet finale con anche la gestione delle FK
ma ahimè, mi ci sto appassionando troppo, mentre dovrei arrivare ad una
soluzione ragionevole e poi passare ad altro
adesso per esempio mi è venuto in mente che per farlo veramente "bulk"
dovrei fare il truncate della tabella, generare un csv e poi far fare il
COPY a postgres
(COPY che, per inciso, è una vera scheggia: impressionante!)
Ma, mannaggia a me, in questo caso ho bisogno solo di buttare dentro a
martellate qualche decina di migliaia di record
Uno spooler di uWSGI e qualche minuto di elaborazione e l'utente è
contentissimo anche se passo per l'ORM, in fondo che gliene frega a lui,
basta che le righe ci siano
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Pycon6: grazie a tutti!

[Enrico Bianchi]

On 04/20/2015 12:06 PM, Carlos Catucci wrote:
Grazie Marco, ma il coltello devi impugnarlo meglio, vedi cosi' rischi 
di non fare male a sufficienza ;)

Cosi`? http://img-9gag-fun.9cache.com/photo/aQ4yQP7_700b_v1.jpg

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

Re: [Python] MySQL vs PgSQL: ne resterà solo uno! Re: Proposta di collaborazione

[Roberto Polli]

Il 21 aprile 2015 11:12, Enrico Bianchi  ha scritto:
> per creare un'utenza praticamente devo
> confermare il fatto che esso sia creato..
> FLUSH PRIVILEGES.
Versione di mysql? Puoi riprodurre?

Nello specifico FLUSH PRIVILEGES *ricarica* mysql.user in memoria, non
"conferma" la creazione degli utenti.

iirc  è necessario solo se modifichi gli utenti via SQL (eg. DELETE
FROM mysql.user ...) e non se usi le GRANT.


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

Re: [Python] Pycon6: grazie a tutti!

[Carlos Catucci]

2015-04-21 11:43 GMT+02:00 Enrico Bianchi :

> Cosi`? http://img-9gag-fun.9cache.com/phCosi`?
> 
> http://img-9gag-fun.9cache.com/photo/aQ4yQP7_700b_v1.jpg
>
> Enrico :Poto/aQ4yQP7_700b_v1.jpg
> 
>
> Enrico :P
>

Geniale. Ecco perche' io, a parte ora che non lo uso piu' l'orologio, e
quando lo facevo lo tenevo al contrario (quadrante im basso) non prendero'
mai unno smartwatch.

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

Re: [Python] MySQL vs PgSQL: ne resterà solo uno! Re: Proposta di collaborazione

[Enrico Bianchi]

On 04/21/2015 12:02 PM, Roberto Polli wrote:

iirc  è necessario solo se modifichi gli utenti via SQL (eg. DELETE
FROM mysql.user ...) e non se usi le GRANT.


Se non ricordo male, me lo richiedeva anche con i comandi di GRANT, ma 
non ricordo ne quale versione, ne quali fossero i comandi esatti...


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

Re: [Python] Pycon6: grazie a tutti!

[Gollum1]

Il 21 aprile 2015 12:06:53 CEST, Carlos Catucci  ha 
scritto:
>
>Geniale. Ecco perche' io, a parte ora che non lo uso piu' l'orologio, e
>quando lo facevo lo tenevo al contrario (quadrante im basso) non
>prendero'
>mai unno smartwatch.

Concordo... neppure io lo uso più da tempo... e quando lo usavo, lo tenevo sul 
braccio opposto.

Byez
-- 
Gollum1
Teoro, dov'è il mio teoro

Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli 
errori di battitura (maledetto correttore automatico).
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Pycon6: grazie a tutti!

[Alessandro Re]

Aggiungo anche io dei ringraziamenti, perché quest'anno ho vissuto la
Pycon in modo diverso, per la prima volta dopo essere entrato nella
mailing list, e ho avuto modo di conoscere alcuni di voi; mi ha fatto
molto piacere e spero di rivedervi l'anno prossimo - e di conoscere
qualcuno in più :)

E sì, l'evento è stato proprio bello in generale, quindi grazie per
averci fatto parte ed averlo reso tale.

(Scusa, Carlos :P)
~Ale
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Pycon6: grazie a tutti!

[Carlos Catucci]

2015-04-21 14:34 GMT+02:00 Alessandro Re :

> (Scusa, Carlos :P)


Tranquillo Ale, ho sviluppato una corazza alla ironman per le sfighe che mi
costringono a perdere sempre gli eventi a cui tengo.

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