Version imprimable
Bonjour,
les dictionnaires ordonnées sont maintenant utilisables dans Python 3 : http://docs.python.org/3.1/whatsnew/3.1.html . Le problème est que leur création manque d'une notation abrégée.
Une double accolade sera pas mal car on aurait :
D'un autre côté il serait peut-être mieux de n'avoir que des dictionnaires ordonnés.Citation:
(...) : un n-uplet
[...] : une liste
{...} : un dico
{{...}} : un dico ordonné
Qu'en pensez-vous ?
Perso, je n'ai pas encore utilisé la v3 mais la méthode de déclaration actuelle ne me choque pas. C'est sûr qu'avoir une syntaxe simplifiée est séduisant et resterait dans l'esprit mais {{..}} me pique les yeux d'un point de vue esthétique.
D'un autre côté, il ne reste pas de caractères aussi "compréhensibles" que (,[,{.
Le seul candidat que je verrais c'est <..> mais c'est quand même différent de {..} pour la création de ce qui n'est au final qu'une spécialisation d'un dictionnaire (sans compter les problèmes d'implémentation/interprétation).
Donc, pour conclure, status quo pour moi :D
cela dit, au cas où tu ne le saurait pas, les propositions de modification du langage se font au travers des PEPs mais la proposition seule ne suffira pas, il te faudra aussi l'argumenter sérieusement.
Bof... Perso je me fous pas mal de l'ordre des dictionnaires. Or, ça représente une lourde perte de performances quand même.Citation:
Envoyé par rambc
Pour ce qui est de la notation {{...}}, je la trouve relativement opaque à la compréhension. A première vue, on pense surtout à un dictionnaire contenant des dictionnaires. <...> ne manque pas de charme par contre. Hélas, ces deux caractères sont utilisés pour des comparaisons. (plus petit / plus grand).
Après un rapide coup d'oeuil sur mon clavier, il semble bien qu'on ait fait le tour des caractères à "contenance": (), [] et {}.
Si je devais proposer quelque chose, je pense que ce serait
Pourquoi ? Une belle question :P Eh bien parce qu'il devient clair qu'on parle d'un dictionnaire, tout en spécifiant qu'il s'agit d'un dico trié. De plus, aucun problème au niveau de l'interprétation, puisqu'un < ne peut pas se trouver après un {.Code:{<...}
En plus, on pourrait avec cette syntaxe spécifier le sens du tri:
PS: Cela dit, avec l'arrivée du moratoire, je ne pense pas que ce genre de chose va être acceptée. A moins de ne faire très très vite, et encore...Code:
2
J'ai bien pensé à l'utilisation éxistante < ou > (d'ou le sans compter les problèmes d'implémentation/interprétation) comme caractère de comparaison mais dans une syntaxe comme a=<...>, le > n'est pas suivi de quelque chose, c'est donc que ce n'est pas une comparaison. Cela étant, cela reste coton pour le < par exemple dans le cas ou le dico est éclaté sur plusieurs lignes.Citation:
Hélas, ces deux caractères sont utilisés pour des comparaisons. (plus petit / plus grand
C'est faisable ça rajoute de la complexité pour le compilo et pour l'humain (deux caractères qui changent de signification se lon le sens du vent).
De plus, la syntaxe actuelle permet de spécifier sur quoi trier (index, valeur, fonction, etc...) alors que dans nos propositions, il faut ajouter le formalisme pour cette information, certes, on peut imaginer des trucs comme chaine "interprétée" en premier ou dernier, une fonction lambda, etc... mais à la réflexion, ça me pique aussi les yeux :D
Et pis, le BDFL ayant obtenu (a tord ou à raison, c'est à chacun de voir) le moratoire, je le vois mal le mettre de côté pour un gain aussi minime ou alors, il va falloir être très très persuasif :P