Il serait intéressant de pour toi de comparer le temps d'exécution de ta version avec ceux de ces versions. On y trouve des choses intéressantes en terme de concision et de performances (même si je serais incapable de dire laquelle est la plus rapide) :
utilisation de fonctions dédiées (encode() et translate())
utilisation de dictionnaires pour faire des recherches rapides, une fois construits (complexité algorithmique en O(1)). La méthode get() est souvent oubliée par les débutants qui vont faire un in (voire pire un has_key()) puis un [key], donc 2 recherches au lieu d'une.
utilisation de join() plutôt que += pour concaténer les chaînes.
Sinon sur ton code en particulier, à part la boucle for qu'il faut revoir, j'aurais des petites trucs en plus :
'' est plus rapide que str() (dans le 2ème cas l'interpréteur doit faire une recherche du symbole "str", qui peut être surchargé). La différence est évidemment infime, mais c'est toujours bon à savoir.
0 est plus rapide que int() (même raison).
(je pourrais du coup dire la même chose de list() vs [] ou dict() vs {})
res, tmp = str(), str() => c'est plus efficace (et plus lisible je trouve) de le faire en 2 lignes, car là l'interpréteur doit construire un tuple temporaire en plus et faire l'unpacking. L'unpacking c'est génial dans bien des cas mais pas là.
# Quelques pistes
Posté par GuieA_7 (site web personnel) . En réponse au message Besoin d'avis sur algo Python. Évalué à 6.
Lire le code des autres est très formateur :
http://stackoverflow.com/questions/3269686/short-rot13-function
Il serait intéressant de pour toi de comparer le temps d'exécution de ta version avec ceux de ces versions. On y trouve des choses intéressantes en terme de concision et de performances (même si je serais incapable de dire laquelle est la plus rapide) :
in(voire pire unhas_key()) puis un[key], donc 2 recherches au lieu d'une.Sinon sur ton code en particulier, à part la boucle
forqu'il faut revoir, j'aurais des petites trucs en plus :''est plus rapide questr()(dans le 2ème cas l'interpréteur doit faire une recherche du symbole "str", qui peut être surchargé). La différence est évidemment infime, mais c'est toujours bon à savoir.0est plus rapide que int() (même raison).list()vs[]oudict()vs{})res, tmp = str(), str()=> c'est plus efficace (et plus lisible je trouve) de le faire en 2 lignes, car là l'interpréteur doit construire un tuple temporaire en plus et faire l'unpacking. L'unpacking c'est génial dans bien des cas mais pas là.Amuses toi bien :)