challenge to convert C code to python (prime numbers)

[Adriweb]

c'est pas pour faire mon fayot , mais ce genre de code est beaucoup moins clair et compréhensible qu'algobox , franchement je plains les élèves de seconde qui vont devoir se coltiner ce genre de code , ou alors faut déjà être ingénieur en informatique , je sais pas ..

Les versions en une ligne ? Oui. Mais justement, on s'en plaignait (et ce ne sera pas ca qui sera enseigné/utilisé de toute maniere)

Les versions normales, non, c'est parfaitement clair/compréhensible vu que c'est vraiment une application bete et mechante d'un algo pas forcement optimal, donc si difficulté il y a, c'est pas dans le langage, qui se lit en anglais directement

[parisse]

Quand je parlais d'efficacite, je ne pensais pas a la vitesse pure d'un nterpreteur compare a un autre ou a un compilateur, mais a l'algorithme lui-meme. Par exemple, l'algorithme initial de compsystems est en temps O(n) (en considerant que les divisions se font en O(1)), l'algorithme que j'ai donne est en O(sqrt(n)). En memoire c'est O(1) et O(1). Les algorithmes utilisant des listes sont en O(sqrt(n)) ou pire en memoire, sauf a utiliser des objets tres evolues.

C'est tres bien d'avoir des objets evolues quand c'est necessaire, mais c'est a mon avis nefaste d'en utiliser quand on peut s'en passer comme c'est le cas ici, et ca risque de favoriser des codes "compacts" illisibles que certains trouvent elegants.
D'ou mon reproche sur l'absence de boucle for definie basique en Python (dans la syntaxe, car nul doute qu'une boucle for ... in range(n) est traduit en interne en boucle for basique). Ce qui fait que j'observe chez pas mal d'etudiants ayant appris a programmer en Python un biais a utiliser des boucles while indefinies meme si la boucle for basique existe dans le langage utilise.