Je suis d’accord avec Sam sur les array en PHP, c’est vraiment bâtard comme outil.

En Lua, c’est encore pire ! Les tables peuvent contenir à la fois une partie indicée sur des entiers et une autres indicée sur des clés. Pour pouvoir compter les éléments, il y a plusieurs techniques aussi, dont celle de stocker une clé qui s’appelle “n”, sous certaines conditions, parfois il faut écrire une boucle à la main. Et pour ne rien arranger, les indices commencent à 1 au lieu de zéro (sous prétexte, selon la doc que c’est plus intuitif !!!). Il faut mettre ça en regard de la légèreté du moteur d’exécution, mais pour la propreté LUA peut repasser.

Pour ce qui est de la complexité d’accès dans une hashmap, cela est commun à toutes les hashmaps quel que soit le langage : le terme “hashmap” désigne bien la technique d’implémentation et pas le fait d’associer une valeur à une clé.

Dans aucun autre langage on a une structure de base à qui on demande de faire tout ce bordel. C’est l’API là plus mal foutu de toutes les structures de données que je connaisse.

Et le Lua alors ? Les tables font à la fois liste, dico, structure de données et permettent même de créer des classes !

Mais contrairement à PHP, l’API est certes minimaliste et bien faite.

[HS] C’est quoi ce trombone qui me juge pendant que j’écris mon message ? Si je fait du LaTeX, c’est bien pour ne pas voir sa figure ![/HS]

[…] utilisent le dictionnaire pour montrer une forme ou une autre de compteur.

Rajouter le retour de c[‘z’] :

»» c['z'] += 1 # pas de KeyError
»» c['z']
1 # <--- Oh, un un !
»» c.most_common(2) # et en bonus
[('b', 3), ('a', 2)]


Et pour faire mon fourreur de drosophiles :

Inline comments should be separated by at least two spaces from the statement.

Génial le Clippy ! :·D

C’est un pattern tellement récurent en plus.

Merci pour ce rappel, on commence à tout connaître, mais on se fait toujours surprendre par un truc basique de l’espace qui nous change la vie.

On note que le cas moyen est O(1), mais on peut avoir un extrema maximum à O(n). A noter que N est le nombre max d’élément qu’il y a eu dans le dict, pas la taille de la valeur hashée.

Pour ce qui est de l’implémentation, les valeurs sont dans un array, et l’indice de cet array est calculé via un hash de la valeur. Une bonne explication ici :

http://www.laurentluce.com/posts/python-dictionary-implementation/

L’intérêt du dictionnaire étant qu’accéder à une clé est très rapide (c’est une opération O(1)), tout comme vérifier qu’une clé est présente dans le dico :

O(1) ? je suis curieux de savoir comment.

Ca veut dire :

– si ton hosting te le permet pas la compilation, tu peux l’utiliser
– tu peux l’essayer en copiant juste le dossier du module, sans avoir à l’installer
– tu peux fournir un programme stand alone multi plateforme avec cette lib très facilement
– si tu veux l’utiliser sur ta machine, pas besoin d’installer gcc et les headers python
– tu peux l’utiliser sur des plateformes alternatives sans effort (exemple, android dans kivy)
– marche sur d’autres implémentations de python (pypy, jython, ironpython, brython, etc)

Si le but principal de ta lib est la perf (comme numpy ou pypy) et qu’utiliser le C est le seul moyen d’y arriver, alors utiliser une extension C est une bonne chose, à condition de fournir un bon support de binaires compilés pour pas mal de plateformes. Mais si tu peux répondre à ton cahier des charges en pur Python, alors c’est idéal.

Le plus simple est d’utiliser une lib externe, par exemple l’excellente sorted_container, qui en plus d’être très rapide, est en pur Python.

Question stupide: en quoi c’est un avantage qu’elle soit en pure python? Alors que toute la moitié python se vantent “ouais nous on compilé directement en c tous ce qu’on pouvait pour être le plus performant possible”.

Question de compatibilité?