In [3]: ast.parse('foo(bar="bar", baz="baz")')
Out[3]: <_ast.Module at 0x106864278>

In [4]: t = _

In [5]: ast.dump(t)
Out[5]: "Module(body=[Expr(value=Call(func=Name(id='foo', ctx=Load()), args=[], keywords=[keyword(arg='bar', value=Str(s='bar')), keyword(arg='baz', value=Str(s='baz'))]))])"

In [6]: ast.dump(ast.parse('foo(baz="bar", bar="baz")'))
Out[6]: "Module(body=[Expr(value=Call(func=Name(id='foo', ctx=Load()), args=[], keywords=[keyword(arg='baz', value=Str(s='bar')), keyword(arg='bar', value=Str(s='baz'))]))])"
[/quote]

Poi per ovvi motivi non vuoi usare quella li, e infatti il tizio secondo me se l'e' scritta. E allora se la scriva giusta? :)


> https://stackoverflow.com/questions/4459531/how-to-read-class-attributes-in-the-same-order-as-declared Nota che questo è proprio un esempio di "cosa che si rompe" (e si è sempre allegramente rotta, dall'alba dei tempi delle mataclassi) se *non* usi OrderedDict (cioè, se non ci sbatti il muso e poi impari a usare OrderedDict).

E ancora una volta, tutta questa roba si fa con un sorted dict, se vuoi. Un treemap, come lo chiamavamo prima.

[quote]
> Un problemino dei named parameters?
> se qualcuno cambia copy(a, b) in copy(src=a, dst=b)
> il mock si rompe potenzialemente

Uh, che cosa vuol dire? Che se cambi la signature di una funzione potrebbe rompersi il suo mock? Beh sì, credo che sia vero *in generale*. Stai cambiano la signature di una funzione, caspita. Che tutto il resto intorno si rompa, beh un po' me lo aspetto.
[/quote]

Ah, pensavo fosse piu' chiaro. No, quello e' il call site. Ovvero, se in un punto interno del mio codice cambio il modo in cui chiamo copy, mock si rompe. Ora voglio essere chiaro, non e' che il fatto che mock si rompa e' un problema di Python. Il problema e' che questa cosa dei named parameter introduce *tante* piccole ambiguita'. Quindi se stai usando mock devi stare attento a come fai le asserzioni. Mock decide di essere esplicito (correttamnte secondo zen), ma il punto e' proprio che sotto molti punti di vista le chiamate copy(a,b) e copy(src=a, dst=b) sono la stessa cosa. Ma non sono *davvero* la stessa cosa. E' un dramma? No. E' una cosa che ti fa perdere un po' di tempo di tanto in tanto.

[pythoncode]In [8]: m = mock.MagicMock()

In [9]: m(a=1, b=1)
Out[9]: <MagicMock name='mock()' id='4404144336'>

In [10]: m.assert_called_once_with(1, 2)[/pythoncode]

> Poi certo, se intendi dire: "non sembra che sto cambiando la signature, ma in python è così e questo causa confusione e fa perdere tempo", allora sì certo. La soluzione è non usare named arguments, hai ragione.

E sfortunatamente non e' cosi'. Perche' l'uso (o no) dipende da chi mi chiama, non da me. Che io sappia l'unico modo in pure python di impedire che ti chiamino con named argument e' fare qualcosa come (o varianti sul tema) -- ma ti perdi tanto:

In [11]: def f(*args):
    ...:     a, b = args


> Maddai... davvero io non ne capisco molto, ma ultimamente vedo (per esempio) tutta questa ansia di produrre build deterministiche...

Non capisco di cosa parli... ma potrebbbe essere che semplicemente tanti dei niubbi che prima finivano in altri lidi ora arrivano qui?

> Ora, il punto è che tutto quello che origina da un dizionario e finisce in qualche modo in un... file di testo (per dire... un output serializzato), non è deterministico.

Boh... se mi serve un certo ordine usero' quell'ordine. Se non mi serve, non lo usero'.

> Non è bello, in certi casi, avere un dizionario ordinato? E non ci pensi più.

Non ci pensi piu'? Abbiamo deciso che l'ordine di output e' importante (se no non lo stiamo facendo).
Per cui ... o speriamo che il dizionario prodotto in un altro punto del codice, magari giorni prima, abbia ancora l'ordine che vogliamo in output oppure lo dobbiamo... riordinare. Non vogliamo farlo? Bene: abbiamo fatto si che un vincolo su uno specifico caso di serializzazione si propaghi fino alla creazione dell'oggetto. E preghiamo forte che non dobbiamo serializzarlo con un altro ordine da un'altra parte. Se no siamo fottuti (oh, certo, possiamo deciedere che uno dei due e' di prima classe... poi i tiZi che scrivono gli altri use-case si chiedono perche' a loro e' andata male).

Ah... oppure ce ne fottiamo e riordiniamo il dizionario ordinato (o ne creiamo uno nuovo con l'ordine giusto). E allora chissene frega dell'ordine del dizionario: ordinero' le chiavi mano mano che le tiro fuori, no?

Il punto e' che se per te e' ok che un vincolo su come devi serializzare una struttura determina come la devo creare, abbiamo visioni su quello che sia un buon design non compatibili. E per me e' talmente ovvio che e' una cattiva idea  he non riesco nemmeno a spiegarti perche' (cioe', posso nominare principi, pattern... ma e' tutta roba nota che sono sicuro tu sappia: se non ti hanno convinto quegli autori, non ho l'arroganza di riuscirti).

Non e' che mi dia fastidio il dizionario ordinato. Sono sicuro che troviamo use case in cui davvero e' la cosa comoda (magari perche' quello che ci interessa e' appunto l'ordine di inserimento). Il problema e' che la maggior parte degli use-case che sento per lui sono use-case in cui viene abusato e di fatto quello che interessa e' che abbia un certo ordine.
In particolare, crei una dipendenza fra come costruisci l'oggetto e come lo visiti (perche' stai spingendo questa logica nel concetto, di per se agnostico, di mappa).

> Oppure più banalmente (e in un altro campo), se faccio i test con doctest, che per forza di cose non può far altro che confrontare stringhe, mi piacerebbe eccome avere dei dizionari order-preserving, o no?

Ok. Dimmi quando questa cosa ha fine. Perche' qui il pattern e' giustifichiamo cattive idee mostrando che se ho altre cattive idee queste diventano piu' semplici. Poi mi si chiede perche' gradualmente mi allontano da Python. :)

Cioe' doctest grandioso. Il suo scopo principe per cui e' davvero grandioso e' che risolve brillantemente il problema in cui ho del codice nella documentazione e lo devo tenere valido. E' egregio e se non ci fosse il mondo sarebbe piu' complicato. Ovviamente *puoi* pensare di usarlo per i test. Tipo se hai una funzione di 10 righe con un happy path e due failure mode. E lo fai quando l'alternativa sarebbe "no test".

Ma ancora uan volta... a me non capita di scrivere funzioni di 10 righe che vivono in isolamento (tipo prendono due interi e una stringa). Insomma... nella maggior parte dei casi voglio pytest. E grazie: contestalo. Tutti stronzi quelli che hanno scritto pytest perche' tanto basta doctest, no? Ma oggettivamente, basta un file pieno di assert una dietro l'altro, no? "basta".

E ora vogliamo ordinare i dizionari per rende piu' facile un'anti-pattern: quello di verificare le strutture dati transformandole in stringhe e poi contollando che sono uguali. Di questo stiamo parlando alla fine... :)

[quote]
E poi ci sono delle volte in cui proprio non ho capito se sono io scemo o cosa:

> Io trovo il discorso: ho implementato gli argomenti
> delle funzioni con un dizionario, ma il dizionario
> non va bene, quindi modifico tutti i dizionari
> completamente delirante. Se per te questa linea di
> ragionamento e' sensata, non c'e' spazio per discutere.
> Abbiamo una visione di software engineering drammaticamente diversa

> Ma no, dai. (Ok, qui potrei dirti che se i core devs di python - Guido compreso - hanno preso questa decisione, proprio deliranti magari non sono... ma sarebbe un falso argomento, si capisce).
[/quote]

Puoi perfino prendere una decisione giusta per motivi deliranti. O prendere una decisione sbagliata per ottimi motivi.
Specificamente ha senso ottimizzare i dizionari? Si, sempre. O meglio: ha senso ottimizzare le cose sul path delle chiamate dei metodi? Certo.
In certi contesti ci si pone perfino il problema di non avere metodi virtuali perche' sono lenti (e.g., C++, Rust). Java minimizza il problema per via del JIT. Python paga tutto. Vogliamo fargli pagare un po' meno. Buona idea. "Tutti" chiamano metodi. Non e' sempre critico, ma e' un buon posto dove ottimizzare

> A parte che non hanno modificato i dizionari *per* ordinare i named arguments... diciamo che è stato un concorso di ragioni... ma anche se fosse così: non c'è qualcosa di sbagliato in quello che scrivi?

Boh, forse. Ovviamente se pensassi di si, non lo farei. ;)
E no, penso che forzare tutti i dizionari di Python ad essere ordered dict per questa cosa non e' una buona idea.

> Non è "modifico tutti i dizionari"... ma è "estendo" i dizionari, o no? Stiamo violando il principio di sostituzione qui? Tutto quel che potevi fare con i vecchi dizionari puoi farlo anche con i nuovi, o no? C'è un problema che non vedo?

Il mio problema non e' che scelgano un comportamento fra i tanti implementation defined. Il mio problema e' che questo diventi un vincolo. E capisco: nel momento in cui per alcuni anni tutti sono abituati che i dizionari sono ordinati (e la gente ci farebbe affidamento), non sarebbe comunque possibile tornare indietro facilmente, anche senza renderlo ufficiale.

Forse verrebbe da dire che il fatto che tutto il macchinario di OOP di Python si fondi sulla stessa struttura dati user-facing che usiamo in 27 altri modi e posti non e' la migliore idea (diverso pattern d'uso?). E ovviamente poi siccome questa cosa del dizionario e' molto leaky come abstraction questa cosa potrebbe essere inevitabile.

Diciamo che arriviamo al punto critico: ho scritto Python per piu' di 15 anni. Quello che si fa con un computer pero' cambia. Anche le cose in cui una piattaforma e' forte e debole cambiano con gli anni (e.g., il GIL non era davvero un problema su macchine con 2 core, adesso e' un dramma e si s

[quote]
Beh, no. Ci sono due aspetti separati qui: primo, i named arguments. Su questi, il vincolo implementativo non è stato introdotto adesso, ma proprio dall'inizio. Se li implementi con un dizionario, ti porti dietro i difettucci dei dizionari, e sei destinato a cambiare la loro semantica tutte le volte che cambi i dizionari. E' un peccato, certo, ma un peccato antico non recente. E da un punto di vista di design, ci sono pochi dubbi che i named arguments *dovrebbero* essere ordinati: a parte le applicazioni pratiche (metaclassi, etc), averli non-ordinati è un attrito cognitivo inutilmente crudele (e già il sistema dei parametri delle funzioni in Python non è proprio una perla di chiarezza, diciamolo). Quindi ben venga la patch tardiva.
[/quote]

E anche qui... il problema in effetti sono i named arguments. Perche' mentre viene istintivo considerarne l'ordine quando si definisce la funzione (anche perche' e' sempre possibile chiamarla senza i nomi), invece nei punti di chiamata l'ordinamento non e' rilevante (e meno male, visto che e' uno dei "vantaggi" che i named arguments portano).

Secondo, i dizionari. Certo, adesso è stato introdotto un vincolo implementativo: se in futuro, per dire, qualcuno dovesse fare un dizionario ancora più performante *ma* non order-preserving, non potrebbe più inserirlo dentro python. Occhei, sono d'accordo.

>  Ma d'altra parte, l'evoluzione verso un dizionario order-preserving è nella natura delle cose,

No. Non e' nella natura delle cose. E' una scelta come un'altra. Quella che fa Ruby, per esempio. Go prende la scelta opposta: *randomizza* l'ordine di enumerazione. A me pare un po' estremo, ma certamente evita il problema che qualcuno possa pensare per piu' di 10 nanosecondi che una mappa e' una struttura ordinata.

> Ora so che adesso ti metti a smattare, ma a un certo punto un linguaggio vale anche perché è usato, e se la gente si aspetta i dizionari order-preserving, vuol dire che è una soluzione comoda in un certo numero di casi d'uso.

Tutt'altro. Questo e' il punto chiave (non sono d'accordo sul "vale se e' usato", da persona che pensava che python valesse quando non era usato). E non sono d'accordo nemmeno che sia una soluzione comoda. Tutti i casi d'uso presentati si risolvono con un sorted dict. Il punto e' che questo e' un testamento. Si sono accorti che con l'utenza odierna di Python l'attrito cognitivo era troppo. E *fanno* bene a farlo, se la situazione e' questa. Pero' sarebbe anche molto triste. O forse nemmeno. E' triste perche' dopo tutto sapere qualcosa di strutture dati non serve ad una mazza. Cioe', serve di tanto in tanto, figurati. Ma non particolarmente piu' di altre cose.

E si, mi sono amminchiato su questa cosa. Python 3.7 e' davvero meglio di 2.7.  E oggettivamente nella pratica non mi cambia *nulla*. Mi avrebbe fatto piu' piacere un sorted dict che mi avrebbee dato cose che dict non mi da? Si. Certo. Me lo posso sempre scrivere, voglio dire. :)

[quote]
Guarda javascript (ecco, adesso smatti: te l'avevo detto). Per anni la gente ha ciclato su Object aspettandosi che fosse order-preserving. Adesso finalmente hanno Map: il risultato è che tutti usano Map nello stesso modo in cui (speravano di) usare Object. Per anni quelli di Chrome sono andati avanti a litigare con gli sviluppatori su questo (https://bugs.chromium.org/p/v8/issues/detail?id=164#c83 ma tutto il thread...), mentre mettevano patch per sistemare piccoli bachetti, cose da nulla capisci... tipo che *il feed di Facebook* su Chrome non veniva ordinato giusto... Ma se alla fine pure i devs di Facebook sono dei niubbi che non sanno usare le strutture-dati corrette, non so, qualcosa di sbagliato ci sarà. Alla fine, devi leggere l'ultimo commento del thread: "Previously, our customized JSON parser generated a separated array of the properties on the insertion order on a Object. Now, we switched to Map everywhere". Ecco fatto, tanto ci voleva, problema risolto, passiamo ad altro.
[/quote]

Stiamo sempre parlando di cambiare l'implementazione per fixare i bachi alla gente. Perche' i bachi sono bachi. E' una buona idea? Boh. Nel breve tempo sembra una buona idea. Io ho paura delle ripercussioni a medio termine. Ci sta anche che sia davvero il trend dei linguaggi con tipizzazione dinamica... per i quali oggettivamente il concectto di array associativo ha similiarita' notevoli con alcune proprieta' core del concetto di oggetto. Forse e' davvero una buona idea.  Pero' c'e' il caso he si sposti solo il problema.

Hai sicuramente reso complicata la vita a tutti quelli che devono supportare Python < 3.5. Ovviamente se hanno best practice no, non gli hai creato un gran problema. Se pero' non e' cosi'....
E va bene. Potrebbe anche essere un trade off accettabile.