Quitte à continuer dans le hs, Candide, si c'est pas indiscret tu enseignes à quel niveau? Penses-tu qu'il y a des tranches d'âges qui sont plus à même de préférer certaines pratiques à d'autres (e.g. des plus jeunes mieux comprendre un while qu'un for...in... alors que ça serait l'inverse pour des élèves plus âgés? ou vice-versa?).
Je ne suis pas informaticien, je fais de l'appoint quand on me le demande et en fonction de mon service, en fait j'enseigne essentiellement en licence de maths et de la théorie des graphes en licence d'info (avec des TP). Pour ta dernière question, je ne peux pas y répondre, je dirais d'après ma modeste expérience que les étudiants réagiront en fonction de ce qui bousculera moins leurs habitudes et de ce qu'ils auront appris en premier. À mon avis, ça dépend moins de l'âge de l'étudiant que de son profil ; certains n'aiment pas qu'on leur cache le fonctionnement, d'autres préfèrent les fonctionnements automatiques.
for/in est plus rapide que while condition (puisque pas de condition supplémentaire), je pense que c'est une raison suffisante ...
Oui enfin il y a une condition dans le range c'est juste qu'on ne la voit pas (ça ne m'empêche pas de penser que for...inrange(...) est probablement plus rapide car c'est built-in).
c'est bien ce que je dis "(puisque pas de condition supplémentaire)" ...
Par exemple, bon nombre de programmeurs, y compris des programmeurs professionnels pensent que x+=1 est équivalent à x=x+1. C'est pourtant faux.
Pour ce qui est des nombres, et tout autre objet non-modifiable, ces syntaxes sont totalement identiques. Tout du moins, c'est ce que je crois et si quelqu'un peut me prouver le contraire, je suis tout ouïe.
Par exemple, bon nombre de programmeurs, y compris des programmeurs professionnels pensent que x+=1 est équivalent à x=x+1. C'est pourtant faux.
Pour ce qui est des nombres, et tout autre objet non-modifiable, ces syntaxes sont totalement identiques.
Sois plus précis car une formulation impersonnelle du type Pour ce qui est est typiquement floue. Même le terme nombre est vague (nombre peut désigner un constante littérale, une variable qui est liée (bounded) à un nombre).
Par ailleurs, ipso facto, les syntaxes NE sont PAS identiques (x+=1 n'est pas identique à x=x+1), d'ailleurs j'ai employé le terme de équivalent. Il faut exprimer avec beaucoup de précision lorsqu'on commence à gloser sur des points délicats de la syntaxe ou de la sémantique d'un langage (typiquement en C quand on parle de pointeur, il faut peser et sous-peser chacun des termes qu'on emploie, dire qu'un tableau est un pointeur et t'as déjà tout faux).
Ce que je voulais dire c'est que ces deux syntaxes ont le même comportement avec tous les objets non-modifiables (int,str,tuple,etc...). Et j'irais même plus loin en disant qu'elles utilisent toutes les deux les même méthodes et dans le même ordre (par exemple : obj = obj.__add__(other)).
Ce que je voulais dire c'est que ces deux syntaxes ont le même comportement avec tous les objets non-modifiables (int,str,tuple,etc...).
[Désolé mais c'est pas tellement plus clair.]
"avec tous les objets non-modifiables" : vague.
"comportement" : de quoi ?
Réfère-toi aux énoncés précis à savoir x+=1 et x=x+1.
Veux-tu dire que dans tout programme Python tel que x est une expression (pas forcément un identificateur) de valeur int, alors on peut remplacer l'instruction x+=1 par x=x+1 tout en ayant des exécutions identiques càd qu'après exécution de chacune des deux instructions dans leur progammes respectifs, l'état de la mémoire des programmes est identique ? Si c'est ça que tu penses, et bien ce n'est pas exact.
Oui c'est ce que je veux dire. La methode int.__iadd__ n'existe pas donc python appel int.__add__ puis affect le resultat. Du moins, c'est ce que la doc semble dire.
Et, à priori, les objets non-modifiables (c'est ainsi que l'on nomme les objets Python qui ne peuvent être modifiés, non ?) n'ont pas besoin de faire la différence entre ces deux méthodes contrairement au liste, par exemple, qui dans un cas concatène dans le même objet et dans l'autre cas crée un nouvel objet.
An augmented assignment expression like x += 1 can be rewritten as x = x + 1 to achieve a similar, but not exactly equal effect.
À partir de là, si tu as compris le problème, il est facile de créer un petit contre-exemple, certes un peu tiré par les cheveux :
# Python 2.7
def f(t):
for i in range(len(t)):
t[i]+=1
return 1
t = [42, 42]
t[f(t)] += 1
print t
t = [42, 42]
t[f(t)] = t[f(t)] + 1
print t
[43, 44]
[44, 44]
Dans mon code, on a bien x qui est une expression de type int. Les programmes ne sont pas équivalents puisque l'état de la liste t est différent dans chaque cas.
c'est pas pour en rajouter sur ce qui a été dit, mais simplement pour souligner combien certaines contradictions peuvent être perturbantes pour un débutant, qui est prêt à croire ce qu'on lui raconte sans broncher
extrait de 'Introduction à Python 3' de Robert Cordeau :
dans le chapitre 2 : La calculatrice Python
2.6.4 Les variantes de l'affectation
Citation
Outre l'affectation simple, on peut aussi utiliser les formes suivantes :
[...]
# affectation augmentée
v += 2
# idem à : v = v + 2 si v est déjà référencé
c'est pas pour en rajouter sur ce qui a été dit, mais simplement pour souligner combien certaines contradictions peuvent être perturbantes pour un débutant, qui est prêt à croire ce qu'on lui raconte sans broncher
Tous les débutants ne sont pas comme ça
Citation : peyo78
extrait de 'Introduction à Python 3' de Robert Cordeau :
Lien, merci.
Citation : peyo78
extrait de 'Introduction à Python 3' de Robert Cordeau :
dans le chapitre 2 : La calculatrice Python
2.6.4 Les variantes de l'affectation
Citation
Outre l'affectation simple, on peut aussi utiliser les formes suivantes :
[...]
# affectation augmentée
v += 2
# idem à : v = v + 2 si v est déjà référencé
Bon, dans 99% des cas, il y a équivalence donc cette erreur n'est pas très gênante. Par contre, il y a une chose dont je ne suis pas certain, c'est si Python optimise ou pas x = x + ma_chaine, ce qui est le cas pour x+=ma_chaine (cf. la doc de référence).
Donc, je ne reprocherais pas cette menue erreur à Cordeau mais je trouve son cours très mauvais du point de vue de la qualité des explications fournies et de la progression, la présentation est soignée mais à part ça, pas grand chose.
Python c'est bon, mangez-en.