Re: N'optimiser que si nécessaire

Et pour chaque accès aux valeurs il faut se farcir la recherche dans la table en question (hachage du nom recherché, puis recherche). Ces opérations sont bien plus coûteuses que si s'était "rangé en vrac", à condition de ne pas avoir trop de valeurs.

Oui, bien sûr. Et comme ça un attaquant peut profiter du fait que les recherches sont en O(n). C'est quoi le sujet de la dépêche déjà ?

Au fait, pour le côté "bien plus coûteux que si c'était rangé en vrac" :

$ ./python -m timeit -s "vars=['a', 'b', 'c', 'd']" "vars.index('c')"
10000000 loops, best of 3: 0.155 usec per loop
$ ./python -m timeit -s "vars={'a':1, 'b':2, 'c':3, 'd':4}" "vars.get('c')"
10000000 loops, best of 3: 0.0751 usec per loop

Déjà avec 4 entrées, la table hash est deux fois plus rapide que la table "en vrac".

le programmeur, sachant qu'il n'y a pas de table de hachage, les fourre dans une qu'il construit pour l'occasion et le tour est joué

Oui, tiens, c'est une bonne idée ça, de laisser le programmeur se faire chier à reprogrammer sa propre table hash, correctement optimisée, à chaque occasion. Laisse-moi deviner, tu es aussi contre la gestion automatique de la mémoire parce c'est aussi simple d'appeler free() au bon moment ?

En fait tu voudrais que les langages haut niveau ressemblent au C, mais à ça il y a une solution très simple : programme en C. Problème résolu :-)