Posté par gasche .
En réponse à la dépêche Python 2.7.
Évalué à 3.
Il me semble qu'OrderedDict ne permet pas d'associer un ordre (choisi par le programmeur) aux clés, mais se contente de conserver l'ordre d'insertion. En tout cas, c'est ce qu'indique la PEP 372 :
« Does OrderedDict support alternate sort orders such as alphabetical?
No. Those wanting different sort orders really need to be using another technique. The OrderedDict is all about recording insertion order. If any other order is of interest, then another structure (like an in-memory dbm) is likely a better fit. »
Je vois quelques cas où on a envie de donner un ordre sur les clés d'une table associative (typiquement, dans les langages où ces tables sont implémentées par des arbres équilibrés, l'implémentation demande déjà un ordre, et propose des fonctions d'itération qui garantissent de parcourir les éléments par ordre croissant des clés par exemple, et je m'en suis déjà servi dans de rares cas).
J'ai beaucoup plus de mal à trouver un bon exemple (qui soit naturel, et où ce n'est pas juste un hack) où l'ordre voulu est précisément l'ordre d'insertion des éléments. Je ne doute pas que ça existe, mais j'ai l'impression qu'il y a beaucoup de mauvais exemples et peu de bons exemples.
Qu'est-ce qui te fait dire que c'est "du lourd" ? Tu as des exemples intéressants à nous montrer où tu as senti le besoin de cette structure de données ? Je pense que ce serait une bonne idée d'agrémenter ce changelog un peu brut par une discussion réelle des fonctionnalités : comme je l'ai dit, je pense qu'il serait bon d'avertir les gens des risques de mauvaise utilisation (attributs XML), mais des bons exemples seraient encore plus sympas.
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par gasche . En réponse à la dépêche Python 2.7. Évalué à 3.
« Does OrderedDict support alternate sort orders such as alphabetical?
No. Those wanting different sort orders really need to be using another technique. The OrderedDict is all about recording insertion order. If any other order is of interest, then another structure (like an in-memory dbm) is likely a better fit. »
Je vois quelques cas où on a envie de donner un ordre sur les clés d'une table associative (typiquement, dans les langages où ces tables sont implémentées par des arbres équilibrés, l'implémentation demande déjà un ordre, et propose des fonctions d'itération qui garantissent de parcourir les éléments par ordre croissant des clés par exemple, et je m'en suis déjà servi dans de rares cas).
J'ai beaucoup plus de mal à trouver un bon exemple (qui soit naturel, et où ce n'est pas juste un hack) où l'ordre voulu est précisément l'ordre d'insertion des éléments. Je ne doute pas que ça existe, mais j'ai l'impression qu'il y a beaucoup de mauvais exemples et peu de bons exemples.
Qu'est-ce qui te fait dire que c'est "du lourd" ? Tu as des exemples intéressants à nous montrer où tu as senti le besoin de cette structure de données ? Je pense que ce serait une bonne idée d'agrémenter ce changelog un peu brut par une discussion réelle des fonctionnalités : comme je l'ai dit, je pense qu'il serait bon d'avertir les gens des risques de mauvaise utilisation (attributs XML), mais des bons exemples seraient encore plus sympas.