Transition algorithmique collège/lycée

Par exemple.

BR a écrit:

nc33 a écrit:Bonjour, une question en passant pour Python : je suis parti sur Spyder via Anaconda (un peu lourd/long à installer et à ouvrir). Je précise que veux les faire travailler sur pc et qu'il n'y a pas internet. Aurais-je pu faire un meilleur choix ?

Je conseillerais plutôt d'installer WinPython qui propose plusieurs éditeurs de code : Idle, Pyzo, Spyder mais aussi Jupyter... Si je ne me trompe pas, WinPython intègre tous les modules proposés par Anaconda (dont numpy, scipy, matplotlib) et propose un environnement portable : il suffit de recopier le dossier WinPython sur une clef USB (ou d'une clef USB sur un ordinateur) pour pouvoir l'utiliser directement depuis le dossier que l'on a recopié.

Cerise sur le gateau : WinPython fonctionne. On ne peut pas en dire autant des dernières versions d'Anaconda, que je n'ai jamais réussi à faire fonctionner convenablement (avec un beau plantage dès que je cherche à utiliser numpy).

Oui mais Windows only … rédhibitoire pour moi.

Simeon a écrit:Sur la syntaxe de Python, ce qui revient comme critique, c'est le = pour l'affectation, le for/range, l'indentation pour délimiter les blocs, et le typage dynamique. Je suis d'accord sur le =, mais Python suit quand même la masse sur ce point. Pour le for/range, je pense que s'en servir comme un répéter, et privilégier le while au moins au début via à bout de ce problème.

La logique de la boucle for en Python n'est pas si mystérieuse.

Je vous invite à lire l'article de Dijkstra : Why numbering should start at zero qui passe en revue les différentes conventions possibles pour les boucles. On peut raisonnablement penser que Dijkstra a suffisamment pratiqué la programmation pour avoir un avis éclairé sur les conventions les plus pratiques en informatique.

Pour noter les entiers 2,3,...,12, écrit Dijkstra, nous avons quatre conventions possibles :
a. 2 ≤ n < 13
b. 1 < n ≤ 12
c. 2 ≤ n ≤ 12
d. 1 < n < 13

Dijkstra remarque qu'avec les conventions a. et b., le nombre d'éléments correspond à la différence entre les bornes de l'inégalité, ce qui lui paraît une propriété intéressante. De plus, lorsque l'on a deux suites adjacentes, la borne supérieure des inégalités définissant l'une des suites est égale à la borne inférieure des inégalités définissant l'autre suite, ce qui est également une propriété intéressante (cela évite de jongler avec les décalages d'indice).

Si on veut faire n itérations, on peut itérer pour i tels que 0 ≤ i < n ou 1 ≤ i < n+1 : il est clair que la seconde convention manque d'élégance.

Dijkstra a écrit:And the moral of the story is that we had better regard —after all those centuries!— zero as a most natural number.

Bref :

• range(a,b) correspondant à l'intervalle [a,b[ et a pour longueur b-a,
  
• range(n) permet de faire une boucle de n itérations.
  

BR a écrit:

• range(a,b) correspondant à l'intervalle [a,b[ et a pour longueur b-a,
  
• range(n) permet de faire une boucle de n itérations.
  

On peut aussi remarquer que la représentation des entiers signés sur n bits utilise la convention de Dijkstra : ainsi, les nombres entiers signés sur 64 bits correspondent à l'intervalle [-2**63,2**63[ (c'est à dire range(-2**63,2**63) avec la notation de Python).

VinZT a écrit:

BR a écrit:Je conseillerais plutôt d'installer WinPython qui propose plusieurs éditeurs de code : Idle, Pyzo, Spyder mais aussi Jupyter... Si je ne me trompe pas, WinPython intègre tous les modules proposés par Anaconda (dont numpy, scipy, matplotlib) et propose un environnement portable : il suffit de recopier le dossier WinPython sur une clef USB (ou d'une clef USB sur un ordinateur) pour pouvoir l'utiliser directement depuis le dossier que l'on a recopié.

Oui mais Windows only … rédhibitoire pour moi.

Si ton environnement informatique au Lycée est Windows only, WinPython est à mon avis une excellente solution, à priori plus fiable qu'Anaconda+Spyder d'après mon expérience.

Ce que tu fais à la maison avec ton ordinateur est une affaire d'adultes consentants : dans ce cas, Anaconda est sans doute un excellent choix sous Mac OS ou sous Linux. C'est d'ailleurs mon choix à la maison, sous Mac OS.

J'ai un mac à la maison … et des macs en classe
Dans ce que tu dis, j'en déduis finalement que le problème dans Anaconda+Windows, c'est Windows

Blague à part, si l'on veut que les élèves installent python chez eux pour faire ce qu'on n'aura pas le temps de faire en classe, une distribution standard et multiplateforme me semble souhaitable. La distribution « officielle » + IDLE et roulez jeunesse … Ou alors, une distribution en ligne, style python tutor ou autre. Tiens en passant, ce que fait LeLivreScolaire, en intégrant des modules python et GeoGebra dans ses pages d'exercices en ligne me semble une bonne idée.

VinZT a écrit:J'ai un mac à la maison … et des macs en classe

Avec Mac OS, je conseillerais volontiers Pyzo+Anaconda.
Mon expérience avec Spyder sous Mac OS n'est guère concluante (bugs, lenteur au démarrage), alors que Pyzo fonctionne comme un charme.

En fait, en ISN, on utilise surtout IDLE, parfois Pyzo ou CodeRunner, ce dernier ayant l'avantage de gérer tout plein de langages et d'avoir une jolie interface. Bien pratique pour saisir des bouts de code, mais payant et Mac only.

Simeon a écrit:Un langage "d'enseignement" populaire fini par devenir un vrai langage utilisé dans la "vraie vie". En grande partie parce qu'il est faux de dire qu'un langage s'apprend vite, c'est vrai pour la syntaxe, mais ce n'est pas le cas pour tout l'écosystème et le mode de pensée qui accompagne le langage.

Et je maintiens que ce "mode de pensée" accompagnant un langage donné et son écosystème relève d'une partie spécifique de l'informatique qui sort complètement du domaine des mathématiques, d'où la nécessité d'une part de séparer les deux enseignements et d'autre part de ne pas confier l'un des deux à quelqu'un qui ne s'y connaît que dans l'autre.

D'ailleurs, alors que j'ai un niveau à peu près correct en maths, rien que la discussion qui émerge dans ce fil autour du choix de la distribution de Python me semble complètement ésotérique.

Simeon a écrit:Je suis d'accord qu'on a ajouté avec l'algo/prog un morceau énorme aux maths sans rien supprimer de substantiel et sans donner d'heures en plus aux maths.
Cependant, je pense qu'il est préférable d'avoir un seul langage pour les maths, la PC, les SVT,  SNT et NSI. Surtout que s'il y avait 2 langages différents en maths et NSI, pourquoi ce ne serait pas le langage utilisé en NSI qui serait privilégié en SNT ? Les collègues de maths qui se retrouveraient avec 2 langages seraient aux anges...
Il y a aussi l'exemple de la PC qui est en train de se planter en se retrouvant à devoir enseigner Python, et le C++simplifié d'Arduino...

Effectivement, il est préférable de ne pas se disperser en utilisant plusieurs langages différents dans chacune des disciplines, mais était-il vraiment nécessaire d'introduire de la programmation en maths, PC et SVT dès le secondaire ?
Je crois qu'on a affaire ici à une forme de lobbying des informaticiens qui, à l'instar de celui des statisticiens nous imposant des statistiques inférentielles au lycée, va se solder par une débâcle pédagogique - et pas uniquement à cause de l'insuffisance du volume horaire.

Simeon a écrit:D'autre part, je trouve que Python a une syntaxe très accessible, et surtout très lisible. Même si écrire du Python peut poser problème, Python est pour moi le langage le plus facile à lire et à comprendre que je connaisse. Or, il semble plus réaliste de demander aux élèves de lire et comprendre du code (et vaguement le modifier à la marge) que de vraiment en écrire.

Sur la syntaxe de Python, ce qui revient comme critique, c'est le = pour l'affectation, le for/range, l'indentation pour délimiter les blocs, et le typage dynamique.
Je suis d'accord sur le =, mais Python suit quand même la masse sur ce point. Pour le for/range, je pense que s'en servir comme un répéter, et privilégier le while au moins au début via à bout de ce problème. Et sur le typage dynamique, je ne comprends ceux qui veulent plus de maths et moins d'infos, mais qui veulent passer plein de temps sur les types.

J'ai tellement peu d'expérience en informatique que je n'avais même pas pensé à présenter le for/range comme une instruction "répéter" avant de lire cette suggestion sur le forum... c'est dire à quel point je suis disqualifié pour enseigner Python.
Effectivement, ce que tu proposes (se servir de for/range comme un répéter et, sinon, privilégier le while) contourne cette difficulté de syntaxe spécifique à Python... au début.
Cependant cela ne règle pas complètement le problème car les algorithmes écrits avec une boucle "pour" sont quand même couramment employés et on ne peut pas indéfiniment les passer sous silence, d'autant plus qu'on n'a aucune garantie qu'un range(1,n) n'apparaîtra pas dans un sujet de Bac.
Tu trouveras peut-être qu'il n'est pas si compliqué d'expliquer que l'instruction for/range est ce que Python a de plus proche d'une boucle "pour" sans être tout-à-fait la même chose (*) et que je me noie dans un verre d'eau, mais depuis la semaine dernière je fais avec mes élèves de spécialité maths de première des révisions sur les tableaux de signe (niveau seconde) et, après des rappels de cours et au moins six exercices, il y en a encore aujourd'hui qui m'ont demandé de réexpliquer pourquoi le tableau de signe de -2x+6 était +0- ; alors à mon avis, faire passer le range(1,8) c'est pas du tout gagné...
Quant aux arguments de Dijkstra cités par BR, ils sont certainement très convaincants pour un expert ou un esthète de l'informatique mais il n'en demeure pas moins que pour un débutant l'instruction for/range de Python est vraiment contre-intuitive... sinon on aurait adopté spontanément la même convention pour les algorithmes en pseudo-code ainsi que pour tous les autres langages.

Concernant le typage, je ne souhaite pas du tout passer plein de temps là-dessus, et il y a sûrement plein de subtilités qui m'échappent, mais il ne me semblerait pas inintéressant de mentionner qu'en informatique on distingue les entiers sur lesquels les calculs sont exacts (dans une certaine marge) et les flottants pour lesquels les calculs sont approchés, la distinction entre une variable qui est vouée à rester entière et une qui peut ne pas l'être appartenant justement à peu près au registre des maths.
Paradoxalement, le typage dynamique de Python me semble compliquer la donne à cause du changement de type implicite que peuvent induire certaines instructions au risque de fournir en fin de compte un résultat erroné (je ne retrouve plus l'exemple, mais il me semble avoir vu passer un programme Python dans lequel une instruction renvoyant implicitement un flottant faussait le résultat, alors qu'en prenant une autre instruction renvoyant un entier, la valeur obtenue était correcte) ; bien sûr l'absence de déclaration préliminaire des variables allège la rédaction d'un programme, mais le typage dynamique oblige à avoir constamment à l'esprit les effets de bords qu'il peut induire. Pour un débutant, l'implicite est généralement plus problématique que l'explicite et je ne suis pas du tout sûr qu'en terme d'apprentissage on gagne vraiment du temps.


(*) Finalement, à la lecture de ce fil, j'en viens à me dire que la traduction en "langage naturel" du for/range(p,n) de Python s'apparente plutôt à "répéter n-p fois en comptant à partir de p", mais dans ce cas, même si je ne suis pas sûr que ce serait très commode à l'usage pour programmer des boucles, il aurait été plus intuitif d'avoir une instruction du style repeat(m,p), qu'on pourrait étendre à repeat(m,p,k) pour "répéter m fois à partir de p en comptant de k en k", les raccourcis repeat(m,p) et repeat(m) signifiant par défaut respectivement repeat(m,p,1) et repeat(m,0,1).  
Quoi qu'il en soit, ce for/range(p,n) en Python est un peu bâtard du point de vue de sa transcription en "langage naturel" puisque, dès qu'on a quelques bases en anglais, le mot "for" fait inévitablement penser à une boucle "pour" qui sous-entend que la valeur initiale et la valeur finale sont toutes les deux incluses dans la boucle.

Moonchild a écrit:Quant aux arguments de Dijkstra cités par BR, ils sont certainement très convaincants pour un expert ou un esthète de l'informatique mais il n'en demeure pas moins que pour un débutant l'instruction for/range de Python est vraiment contre-intuitive... sinon on aurait adopté spontanément la même convention pour les algorithmes en pseudo-code ainsi que pour tous les autres langages.

Les boucles for les plus répandues en C ou en C++ sont similaires à celles de Python:

Code:

for (size_t i=0; i < bidule.size(); i++)

en C++
vs.

Code:

for i in range(0,len(bidule))

en Python.
La différence est qu'en C++ le signe '<' explicite que bidule.size() est exclu des indices de boucle.
En comparaison,

Code:

for i = 0 to 10

en OCaml parcourt les indices de 0 à 10 tous deux inclus.

Moonchild a écrit:pour un débutant l'instruction for/range de Python est vraiment contre-intuitive... sinon on aurait adopté spontanément la même convention pour les algorithmes en pseudo-code ainsi que pour tous les autres langages.

Je pense que l'intérêt d'une syntaxe telle que for x in ... est que l'on peut la faire suivre de tout autre chose qu'un range ou de bornes numériques (l'intérêt du in). Ce qui semble plus dur avec l'autre syntaxe.

Code:


for car in 'bonjour':
    print("Lettre: ", car)


En bash, on peut utiliser la même idée, par exemple pour faire une copie des fichiers du répertoire courant:

Code:


for fic in $(ls);do
   cp $i /sauvegarde/$i.bak
done


Personnellement, j'introduis toujours le for sans exemple de range, puis je présente range (ou seq en bash) et on lie les 2. C'est pas grave mais je vois beaucoup débarquer de premières année qui pensent que for ne fonctionne qu'avec range...

BR a écrit:

nc33 a écrit:Bonjour, une question en passant pour Python : je suis parti sur Spyder via Anaconda (un peu lourd/long à installer et à ouvrir). Je précise que veux les faire travailler sur pc et qu'il n'y a pas internet. Aurais-je pu faire un meilleur choix ?

Je conseillerais plutôt d'installer WinPython qui propose plusieurs éditeurs de code : Idle, Pyzo, Spyder mais aussi Jupyter... Si je ne me trompe pas, WinPython intègre tous les modules proposés par Anaconda (dont numpy, scipy, matplotlib) et propose un environnement portable : il suffit de recopier le dossier WinPython sur une clef USB (ou d'une clef USB sur un ordinateur) pour pouvoir l'utiliser directement depuis le dossier que l'on a recopié.

Cerise sur le gateau : WinPython fonctionne. On ne peut pas en dire autant des dernières versions d'Anaconda, que je n'ai jamais réussi à faire fonctionner convenablement (avec un beau plantage dès que je cherche à utiliser numpy).

D'accord merci, je regarderai (ou Pyzo que quelqu'un a suggéré). Chez moi c'est turtle qui bug pas mal sur Anaconda.

Mathador a écrit:
Les boucles for les plus répandues en C ou en C++ sont similaires à celles de Python:

Code:

for (size_t i=0; i < bidule.size(); i++)

en C++
vs.

Code:

for i in range(0,len(bidule))

en Python.
La différence est qu'en C++ le signe '<' explicite que bidule.size() est exclu des indices de boucle.
En comparaison,

Code:

for i = 0 to 10

en OCaml parcourt les indices de 0 à 10 tous deux inclus.

Marc au Polo a écrit:
Je pense que l'intérêt d'une syntaxe telle que for x in ... est que l'on peut la faire suivre de tout autre chose qu'un range ou de bornes numériques (l'intérêt du in). Ce qui semble plus dur avec l'autre syntaxe.

Code:


for car in 'bonjour':
    print("Lettre: ", car)


En bash, on peut utiliser la même idée, par exemple pour faire une copie des fichiers du répertoire courant:

Code:


for fic in $(ls);do
   cp $i /sauvegarde/$i.bak
done


Personnellement, j'introduis toujours le for sans exemple de range, puis je présente range (ou seq en bash) et on lie les 2.

Tous ceci est fort intéressant si on discute entre profs ou entre passionnés, mais j'aurais la même réaction que Moonchild : c'est bien loin des préoccupations qui seront celles du lycéen lambda.

Parce que la séance de Python type, dans une classe moyenne, ça sera plutôt la foire à l'élève qui a oublié ses codes de connexion au réseau du lycée, à celui qui a oublié qu'il fallait mettre deux points à la fin d'un ligne qui commence par for, et à celui qui ne comprends toujours pas ce que sont une suite d'instructions, une entrée et une sortie.

Marc au Polo a écrit:
C'est pas grave mais je vois beaucoup débarquer de premières année qui pensent que for ne fonctionne qu'avec range...

Évidemment : on ne traite que ce cas en lycée, parce que l'écart entre ce qui est demandé (et les prérequis implicites) et les capacités réelles d'un bon nombre d'élèves incite, même si c'est pédagogiquement contestable, à ne répéter que des cas standardisés à l'extrême et appauvris. Il est possible que cette tendance soit aggravée par le fait que certains collègues ne maîtrisent par ailleurs guère au-delà.

Séance en TS ce matin, un nombre entier grand (4^2019+5) à calculer. Je sors IDLE. Grand cri d'effroi collectif.
Bonne nouvelle : ils ont reconnu que c'était avec ça qu'on fait python
Mauvaise nouvelle : leurs visages en disaient long quant à la maîtrise du machin.

Moonchild a écrit:Effectivement, ce que tu proposes (se servir de for/range comme un répéter et, sinon, privilégier le while) contourne cette difficulté de syntaxe spécifique à Python... au début.
Cependant cela ne règle pas complètement le problème car les algorithmes écrits avec une boucle "pour" sont quand même couramment employés et on ne peut pas indéfiniment les passer sous silence, d'autant plus qu'on n'a aucune garantie qu'un range(1,n) n'apparaîtra pas dans un sujet de Bac.

Oui, l'idée n'est pas de s'arrêter là, mais de s'appuyer ensuite sur le while pour faire comprendre le for.

Moonchild a écrit:Effectivement, il est préférable de ne pas se disperser en utilisant plusieurs langages différents dans chacune des disciplines, mais était-il vraiment nécessaire d'introduire de la programmation en maths, PC et SVT dès le secondaire ?
Je crois qu'on a affaire ici à une forme de lobbying des informaticiens qui, à l'instar de celui des statisticiens nous imposant des statistiques inférentielles au lycée, va se solder par une débâcle pédagogique - et pas uniquement à cause de l'insuffisance du volume horaire.

Il suffit de voir la popularité des jeux/jouets introduisant la pensée informatique ou des entreprises types magic makers. Parmi, les ingénieurs/scientifiques/matheux que je connais presque tous essaient d'introduire leurs enfants relativement tôt à l'informatique (et plutôt sous forme débranché). Si l'EN ne propose rien à ce niveau, ce ne sera qu'une source monstrueuse d'inégalités.
Les RH de l'EN font qu'il ne faut pas espérer de vrais informaticiens en nombre avant longtemps (ou même jamais) et que les mieux placés pour enseigner un peu d'algo/pensée informatique ce sont les enseignants de maths et un peu ceux de PC aussi.

Marc au Polo a écrit:

Personnellement, j'introduis toujours le for sans exemple de range, puis je présente range (ou seq en bash) et on lie les 2.

C'est l'approche que j'utilise en cours d'informatique.
Cela me semble moyen en mathématiques car, d'après ce que j'ai compris, les élèves seront évalués sur du pseudo-code ne proposant pas l'équivalent.

Prezbo a écrit:

Marc au Polo a écrit:
C'est pas grave mais je vois beaucoup débarquer de premières année qui pensent que for ne fonctionne qu'avec range...

Évidemment : on ne traite que ce cas en lycée, parce que l'écart entre ce qui est demandé (et les prérequis implicites) et les capacités réelles d'un bon nombre d'élèves incite, même si c'est pédagogiquement contestable, à ne répéter que des cas standardisés à l'extrême et appauvris. Il est possible que cette tendance soit aggravée par le fait que certains collègues ne maîtrisent par ailleurs guère au-delà.

Je plaide coupable par anticipation car je crois que je viens plus ou moins de découvrir en lisant vos réponses que le for de Python ne marche pas seulement qu'avec range. Bon, en réalité, ce n'est pas tout-à-fait vrai car je me souviens maintenant avoir vu une fois un programme avec un "for x in" suivi du nom d'une liste, mais comme je n'ai pas encore eu l'utilité de ce genre de chose, mon neurone a relégué l'information tout en bas de la pile ; et puis je n'aurais pas spontanément imaginé que ça marchait aussi avec une chaîne de caractère comme le for car in 'bonjour' de l'exemple de Marc au Polo.

Bref, il ne faut pas trop compter sur moi pour relever le niveau.

Simeon a écrit:

Moonchild a écrit:Effectivement, ce que tu proposes (se servir de for/range comme un répéter et, sinon, privilégier le while) contourne cette difficulté de syntaxe spécifique à Python... au début.
Cependant cela ne règle pas complètement le problème car les algorithmes écrits avec une boucle "pour" sont quand même couramment employés et on ne peut pas indéfiniment les passer sous silence, d'autant plus qu'on n'a aucune garantie qu'un range(1,n) n'apparaîtra pas dans un sujet de Bac.

Oui, l'idée n'est pas de s'arrêter là, mais de s'appuyer ensuite sur le while pour faire comprendre le for.

Je crois que je peux plus ou moins percevoir l'idée, mais de là à la mettre en application de façon efficace en classe, c'est une autre affaire. La seule chose dont je suis à peu près sûr c'est que ça doit prendre un temps dont je ne dispose pas et que les exemples tirés d'un contexte mathématique (qui en lui-même pose problème) ne vont pas faciliter la tâche.

Simeon a écrit:

Moonchild a écrit:Effectivement, il est préférable de ne pas se disperser en utilisant plusieurs langages différents dans chacune des disciplines, mais était-il vraiment nécessaire d'introduire de la programmation en maths, PC et SVT dès le secondaire ?
Je crois qu'on a affaire ici à une forme de lobbying des informaticiens qui, à l'instar de celui des statisticiens nous imposant des statistiques inférentielles au lycée, va se solder par une débâcle pédagogique - et pas uniquement à cause de l'insuffisance du volume horaire.

Il suffit de voir la popularité des jeux/jouets introduisant la pensée informatique ou des entreprises types magic makers. Parmi, les ingénieurs/scientifiques/matheux que je connais presque tous essaient d'introduire leurs enfants relativement tôt à l'informatique (et plutôt sous forme débranché). Si l'EN ne propose rien à ce niveau, ce ne sera qu'une source monstrueuse d'inégalités.
Les RH de l'EN font qu'il ne faut pas espérer de vrais informaticiens en nombre avant longtemps (ou même jamais) et que les mieux placés pour enseigner un peu d'algo/pensée informatique ce sont les enseignants de maths et un peu ceux de PC aussi.

Que ces jeux/jouets introduisant la "pensée informatique" soient populaires auprès de certains parents ne signifie pas forcément qu'ils seront efficaces sur le plan des apprentissages.
Quant à l'EN, si elle n'est pas en mesure de mettre en place de véritables cours d'informatique dans le secondaire, j'ai l'impression qu'elle corrigerait beaucoup plus d'inégalités en assurant un enseignement de bon niveau en français et en maths dès le primaire plutôt qu'en faisant semblant de proposer un pseudo-enseignement par des personnels non qualifiés dans un cadre interdisciplinaire inadéquat, tout en rognant au passage le temps consacré aux autres disciplines qui se retrouvent impliquées de force dans cette farce.

Quand j'observe l'incapacité persistante d'un bon nombre de mes élèves à comprendre un algorithme élémentaire avec une seule boucle (par exemple pour le calcul des termes d'une suite définie par récurrence), incapacité confirmée par le collègue en charge de l'ISN depuis que cet enseignement existe, alors que vers 16 ans j'avais appris en autodidacte à programmer ce genre de chose en Basic uniquement grâce à un manuel pour débutant prêté par un camarade de classe féru d'ordinateurs (je ne suis pas allé beaucoup plus loin car tout ça ne m'intéressait pas vraiment), je me dis que le problème actuel ne vient pas de l'absence d'enseignement d'informatique dans le secondaire et ne sera pas du tout réglé par la parodie qui se met en place.

Il est aussi possible d'itérer sur des tuples, et sans mettre les parenthèses cela donne:

Code:

for i in 0, 1, 2:
    print(i)


Comme ça, plus de problème de range

Outre les boucles for, il y a un autre point qui m'agace et qui a posé problème aux élèves hier. Avec input, il faut utiliser float ou int si on veut procéder à un calcul ensuite. J'imagine que cela aurait pu être inutile si Python avait été conçu autrement.

nc33 a écrit:Outre les boucles for, il y a un autre point qui m'agace et qui a posé problème aux élèves hier. Avec input, il faut utiliser float ou int si on veut procéder à un calcul ensuite. J'imagine que cela aurait pu être inutile si Python avait été conçu autrement.

La fonction input est une source importante de confusion pour les élèves, il est recommandé (voire exigé) de ne pas l'utiliser.
Passer par la console permet de se passer de input dans plus part des cas.
(et le fait qu'elle renvoie une chaîne de caractère parait plutôt sain)

Si tu tiens à l'utiliser, donne directement cette portion de code aux élèves, ça n'a aucun intérêt de le leur faire écrire.

nc33 a écrit:Outre les boucles for, il y a un autre point qui m'agace et qui a posé problème aux élèves hier. Avec input, il faut utiliser float ou int si on veut procéder à un calcul ensuite. J'imagine que cela aurait pu être inutile si Python avait été conçu autrement.

La fonction eval est plus appropriée : float("2+2") renvoie une erreur, eval("2+3.") par contre renvoie le nombre réel 5.
La meilleure solution est encore de ne pas utiliser d'input : on définit une fonction, les données en input dans le script devenant les paramètres de la fonction et on utilise la fonction à la console.

Exemple : pour résoudre l'équation d'inconnue x : ax+b=0, on peut demander de faire entrer a, puis b, puis indiquer la solution :

Avec input :

Code:

a=eval(input('a= '))
b=eval(input('b= '))
x=-b/a
print("{} est l'unique solution de l'équation d'inconnue x : {} x + {} = 0".format(x,a,b))

Lorsque a=0, Python lève une exception ZeroDivisionError que l'on peut traiter (en distinguant le cas générique : b!=0 et le cas b=0) :

Code:

a=eval(input('a= '))
b=eval(input('b= '))
if a!=0:
    x=-b/a
    print("{} est l'unique solution de l'équation d'inconnue x : {} x + {} = 0".format(x,a,b))
elif b!=0:
    print("L'équation d'inconnue x : {}*x + {} = 0 n'a pas de solution".format(a,b))
else:
    print("Tous les réels sont solutions de l'équation d'inconnue x : {}*x + {} = 0".format(a,b))


On peut programmer exactement la même chose avec une fonction :

Code:


def equation_lineaire(a,b):
    """
    Paramètres
    ----------
    a,b : réels
    
    Résultat
    --------
    x : réel
        solution de l'équation ax+b=0
    """
    x=-b/a
    return x


Avec ce code, lorsque a=0, le code lève une exception ZeroDivisionError. On peut personnaliser les différents cas (suivant que b=0 ou b!=0), ce qui donnerait le code :

Code:


def equation_lineaire(a,b):
    """
    Paramètres
    ----------
    a,b : réels
    
    Résultat
    --------
    x : réel
        solution de l'équation ax+b=0
    """
    if a!=0:   # Cas générique
        x=-b/a
        return x
    elif b!=0: # Cas générique lorsque a=0
        raise ZeroDivisionError("L'équation d'inconnue x : {}*x + {} = 0 n'a pas de solution".format(a,b).replace("+ -","- "))
    else:      # Cas où a=0 et b=0
        raise ZeroDivisionError("Tous les réels sont solutions de l'équation d'inconnue x : {}*x + {} = 0".format(a,b))


Si on ne souhaite pas introduire d'exception, on peut remplacer raise ZeroDivisionError(message) par print(message). Lever explicitement l'exception est à mon avis plus approprié si on imagine que la fonction que l'on définit est réutilisée dans d'autres contextes.

Dans le code que je propose replace("+ -","- ") est un dernier raffinement qui permet d'afficher "- c" au lieu de "+ -c" lorsque a=0 et b<0 (b=-c)

Intéressant tout ça (je découvre .format et .replace).

La différence entre le code avec input et le code avec une fonction ?
Dans le premier cas, on doit exécuter le script, entrer la valeur de a, valider, la valeur de b, valider avant d'afficher un résultat puis recommencer (exécuter le script, entrer a, b) si on veut faire un nouveau test.

Dans le second cas, on exécute une seule fois le script, puis peut appeler la fonction dans la console autant de fois qu'on le souhaite. Avec la complétion automatique dans la console (ou la possibilité de revenir à la dernière commande entrée avec une seule touche), il est beaucoup plus facile de tester le script avec différentes valeurs.

Mieux encore : on peut prévoir un script de test qui permet de valider (ou pas) les fonctions proposées par les élèves. Les élèves commencent par exécuter leur script, puis le script de test et valident (ou pas) leur fonction. Ici, on peut par exemple tester avec 10 valeurs choisies au hasard pour a (en remplaçant une valeur nulle par 1) et b, puis, lorsque a=0, 3 valeurs choisies au hasard pour b, puis a=b=0 :

Code:

import random
"""
Cas générique (a!=0)
"""
n=10
A=[round(10*random.uniform(-1,1),2) for k in range(n)]
for i,a in enumerate(A):
    if a==0: # remplacer les valeurs nulles par 1.
        A[i]=1.
B=[round(10*random.uniform(-1,1),2) for k in range(n)]
C=(-b/a for a,b in zip(A,B))
tests,erreurs=0,0
for a,b,c in zip(A,B,C):
    tests+=1
    x=equation_lineaire(a,b)
    if x!=c:
        erreurs+=1
        print("Erreur pour a = {} et b = {} : {}*{} + {} = {}".format(a,b,a,round(x,2),b,round(a*x+b,2)).replace("+ -","- "))

"""
Cas où a=0, b!=0 puis b=0
"""
n=3
B=[round(10*random.uniform(-1,1),2) for k in range(n)]
B.append(0)
A=[0 for b in B]
for a,b in zip(A,B):
    tests+=1
    try:
        x=equation_lineaire(a,b)
        if x!=None:
            erreurs+=1
            print("Votre fonction propose {} comme unique solution de {}*x + {} = 0".format(x,a,b).replace("+ -","- "))
    except:
        pass

"""
Conclusion
"""
if erreurs==0:
    print("{} tests passés, pas d'erreurs, la fonction semble correcte".format(tests))
else:
    print("{} tests passés, {} erreurs, corrigez votre fonction".format(tests,erreurs))

Bravo. C'est très joli, et complètement imbitable par les élèves, voire même par la plupart des collègues. En tout cas, pour ma part, avec quelques années d'ISN au compteur, j'ai découvert des choses dans les scripts proposés (ce qui me conforte dans mon idée de passer la main pour NSI).
Reste que ne jamais faire d'entrées/sorties peut se révéler problématique dans certains cas : python intégré dans certains sites (pythontutor, lelivrescolaire entre autres) ou à la calculatrice (NumWorks possède un mode console allégé mais les autres ?)

J'imagine que c'est à titre d'exemple, mais il me parait assez fou de vouloir tester le code des élèves sans passer par une bibliothèque de tests unitaires.
De même, les exceptions ce n'est pas pour les élèves, si ?

Et pourquoi le choix de format plutôt que les f-strings ?

Simeon a écrit:
Il suffit de voir la popularité des jeux/jouets introduisant la pensée informatique ou des entreprises types magic makers. Parmi, les ingénieurs/scientifiques/matheux que je connais presque tous essaient d'introduire leurs enfants relativement tôt à l'informatique (et plutôt sous forme débranché). Si l'EN ne propose rien à ce niveau, ce ne sera qu'une source monstrueuse d'inégalités.

Je ne dois pas être un vrai matheux, alors, parce que j'ai lu des histoires à mes enfants, j'ai joué avec eux aux légos et à des jeux de société, j'ai tenté de les pousser vers des activités favorables à leur développement, je les ai emmenés visiter des trucs culturels, j'ai surveillé de loin que le travail scolaire suivait son cours de façon satisfaisante, je me suis même farci les rencontres avec les enseignants (et cette impression de retourner faire du rab au boulot)...Mais je n'ai pas spécialement essayé de les introduire à l'informatique, même débranchée, ni à quelque activité directement destinée à leur procurer un avantage scolaire. A un moment, je pense que chacun doit rester à sa place, et faire son travail.

Pour sortir de mon cas personnel : les petits génies qui s'amusent depuis leur plus jeune âge avec Magic Maker sont loins de représenter l'élève-type de lycée, même parmi les bons élèves, même parmi ceux qui étaient jusqu'ici en S et qui choisiront maintenant les spécialités maths et peut-être NSI.

Il est possible d'ailleurs que certains informaticiens et matheux de haut vol, ayant fait ce type d'initiation avec leurs propres enfants -qui grandissent dans un contexte familial et culturel exceptionnellement favorable, et n'ont probablement pas eu de difficultés d'entrée dans l'écrit, dans la numération ni dans l'abstraction-, en déduisent que les enfants peuvent beaucoup et que ce type d'initiation est accessible à tous. En oubliant que tous les lycéens n'ont pas bénéficiés des mêmes bases, ni du même contexte.

Un des problèmes est peut-être d'ailleurs non pas d'essayer d'introduire l'informatique, la programmation et Python au lycée, mais de croire que cela est indispensable ou prioritaire pour tous les élèves. Quand je vois mes term STMG de cette année, l'idée qu'il faudra apprendre à leurs successeurs à lire et produire du code informatique me fait rire jaune. Pour l'instant, ils trainent et contestent quand je leur dis qu'une calculatrice est obligatoire, et ont du mal avec les indices base 100.

Etre un matheux ou un informaticien de haut vol ne fait pas automatiquement de vous quelqu'un dont les propositions pédagogiques sont pertinentes, ni réalistes.

Simeon a écrit:

nc33 a écrit:Outre les boucles for, il y a un autre point qui m'agace et qui a posé problème aux élèves hier. Avec input, il faut utiliser float ou int si on veut procéder à un calcul ensuite. J'imagine que cela aurait pu être inutile si Python avait été conçu autrement.

La fonction input est une source importante de confusion pour les élèves, il est recommandé (voire exigé) de ne pas l'utiliser.
Passer par la console permet de se passer de input dans plus part des cas.
(et le fait qu'elle renvoie une chaîne de caractère parait plutôt sain)

Il me semble que le débat a déjà été fait, et que nous sommes quelques-un à trouver caricaturale cette volonté forcenée de se passer de la fonction input(), et plus généralement de la notion d'entrée et de sorties, pour tout présenter selon une approche fonctionnelle. Il me semble d'ailleurs que les programmes de seconde définitifs sont un peu revenus en arrière sur ce point, puisque la notion de fonction n'y est abordée que dans une deuxième partie, après les variables, les types, les instructions élémentaires et les boucles.

Je n'ai jusqu'ici jamais vu un cours de programmation qui commence directement par la programmation fonctionnelle, sans avoir préalablement parlé d'entrée et de sortie et fait un minimum de programmation impérative. Renverser cet ordre traditionnel de présentation me semble un pari pédagogique pour le moins risqué. Un peu comparable, toute proportion gardée, à celui des maths modernes, cette époque où on présentait la théorie des ensembles avant l'arithmétique sur les entiers.

D'ailleurs, vous même, avez-vous souvent écrit un programme dépassant quelques lignes en évitant systématiquement le recours à input et à print ?

J'ai jeté un coup d'oeil sur les exemples et préconisation de BR. S'il s'agit de préconiser des bonnes pratiques pour utilisateurs avancés, c'est très bien, mais c'est encore une fois bien loin des préocupations des lycéens, et de celles de la majorité des profs. A titre personnel, j'admets n'avoir appris à lever une exception que récemment, et dans un tuto Openclassroom (même pas honte).

A noter que les créateurs d'Edupython ont contourné le problème du type du résultat renvoyé par la fonction input() en créant une fonction demande(), qui elle retourne bien un nombre (entier ou flottant selon les cas, je suppose).

C'est une mauvaise solution, d'une parce que je ne trouve pas très malin de méler le français et l'anglais, de deux parce qu'elle contribue à dissimuler le problème que posent les différents types de variables, de trois parce qu'elle incite les élèves à écrire des programmes qui dépendent d'une bibliothèque très spécifique. Mais qu'ils aient utilisé cet expédient montre bien qu'il y a ici un problème pour les lycéens.

Prezbo a écrit:Je n'ai jusqu'ici jamais vu un cours de programmation qui commence directement par la programmation fonctionnelle, sans avoir préalablement parlé d'entrée et de sortie et fait un minimum de programmation impérative. Renverser cet ordre traditionnel de présentation me semble un pari pédagogique pour le moins risqué. Un peu comparable, toute proportion gardée, à celui des maths modernes, cette époque où on présentait la théorie des ensembles avant l'arithmétique sur les entiers.

Cela correspond pourtant à une longue tradition de l'enseignement de l'informatique. Je ne sais pas si tu as déjà entendu parler du langage Logo (qui a donné le module turtle de Python) ou de Scheme mais ce sont deux dialectes de Lisp créés pour l'enseignement (peut être même les deux premiers langages d'enseignement), les dialectes de Lisp ont en général une console interactive intégrée, inutile donc de commencer par des prints/input, c'est plutôt expression puis fonction.
Il y a un excellent livre le SICP qui correspond au cours d'introduction à l'informatique du MIT (ce cours a 40 ans maintenant..) qui illustre ce principe. L'accent est mis dès le départ sur le fait de bien structurer son code, de bien poser les problèmes et les gains de l'abstraction. Il existe un livre qui se veut plus ou moins l'équivalent pour des lycéens.

Les grandes fac américaines dont est issue cette tradition (MIT, Berkeley) ont justement abandonné Scheme/Logo pour leur cours d'introduction et sont passés à Python, mais en gardant le même état d'esprit.

(Logo étant inspiré des travaux de Piaget, le procès en math modernisme n'est pas totalement infondé)

Prezbo a écrit:
Il est possible d'ailleurs que certains informaticiens et matheux de haut vol, ayant fait ce type d'initiation avec leurs propres enfants -qui grandissent dans un contexte familial et culturel exceptionnellement favorable, et n'ont probablement pas eu de difficultés d'entrée dans l'écrit, dans la numération ni dans l'abstraction-, en déduisent que les enfants peuvent beaucoup et que ce type d'initiation est accessible à tous. En oubliant que tous les lycéens n'ont pas bénéficiés des mêmes bases, ni du même contexte.

Un des problèmes est peut-être d'ailleurs non pas d'essayer d'introduire l'informatique, la programmation et Python au lycée, mais de croire que cela est indispensable ou prioritaire pour tous les élèves. Quand je vois mes term STMG de cette année, l'idée qu'il faudra apprendre à leurs successeurs à lire et produire du code informatique me fait rire jaune. Pour l'instant, ils trainent et contestent quand je leur dis qu'une calculatrice est obligatoire, et ont du mal avec les indices base 100.

Je trouve ce genre d'argument dangereux, ils me font en tout cas penser à ceux utilisés pour supprimer l'enseignement de la géométrie. (ce qui m'attriste plus que le manque d'info) Cela dit, je ne vois pas l'intérêt de faire du Python en maths en STMG.

Prezbo a écrit:
D'ailleurs, vous même, avez-vous souvent écrit un programme dépassant quelques lignes en évitant systématiquement le recours à input et à print ?

Je n'ai jamais d'input (sauf quand je code un pendu), j'utilise la console ou argv pour une interface en ligne de commande. Ecrire un input et le "parser", c'est déjà trop long, et c'est plus pratique d'entrer les arguments de son programme dans la ligne qui sert à l'appeler.
Un ou deux print en fin de programme mais ça c'est relativement récent, avant d'apprendre à utiliser un débuggeur j'avais un print une ligne sur deux en cas de bug.