[maths-SNT] Avantages du langage Python

Rwan a écrit:

Par contre non algobox c'était pas bien. Very Happy Un langage qui n'a pas de fonction, c'est mort.

Encore une fois, ça dépend des objectifs.
Tu serais donc pour l'abandon de Scratch au collège?

Aucune illusion à avoir: Scratch, c'est pareil. Poubelle. Ne pas perdre de temps avec cette merde. Allez en discuter avec des élèves de seconde, c'est édifiant.

Rwan a écrit:

et je trouve qu'il a beaucoup trop de pièges pour les débutants

Bah je veux bien des exemples. Je maîtrise très bien Python, et je l'ai enseigné sans problème. Mes élèves n'ont (presque) jamais été bloqués par le langage pour résoudre un exercice.

Code:


>>> A = 1
>>> B = A
>>> B += A
>>> print(A, "==" if A == B else "!=", B)
1 != 2

>>> A = [1]
>>> B = A
>>> B += A
>>> print(A, "==" if A == B else "!=", B)
[1, 1] == [1, 1]

>>> A = [1]
>>> B = A
>>> B = B + A
>>> print(A, "==" if A == B else "!=", B)
[1] != [1, 1]


Code:


>>> def f(x, r=[]):
>>>    r.append(x)
>>>    return x + len(r)
>>>
>>> print(f(0), f(0), f(0))
1 2 3


Rwan a écrit:

Par contre non algobox c'était pas bien. Very Happy Un langage qui n'a pas de fonction, c'est mort.

Encore une fois, ça dépend des objectifs.
Tu serais donc pour l'abandon de Scratch au collège?

voici un premier piège sur B += A et la différence avec B = B + A

def f(x, r=[])

Simeon a écrit:Par contre non algobox c'était pas bien. Very Happy Un langage qui n'a pas de fonction, c'est mort.

voici un premier piège sur B += A et la différence avec B = B + A

Je ne vois pas de raison de présenter cette opération sur les listes au lycée. (et même sur les nombres, je trouve ça inutile)

def f(x, r=[])

Pareil, ça n'est pas à présenter au lycée, c'est éventuellement faisable en NSI où on parle un peu de portée.

Call_BB5A a écrit:
Algobox permet de créer des fonctions locales :

Call_BB5A a écrit:
Et comme il n'est nulle part précisé que cela doit se faire par application de la méthode append() comme L.append(x), on peut très bien utiliser l'opération L += [x] .

Call_BB5A a écrit:
Alors que les programmes de première et terminale demandent de mettre l'accent sur la programmation modulaire en créant des fonctions, c'est l'occasion de rappeler une nouvelle fois la distinction entre une fonction mathématique et une fonction informatique.

Call_BB5A a écrit:

La notation L.append(x) est moins naturelle que l'opération L += [x] pour certains élèves à qui on demande d'ajouter le nombre x à la liste L. Entre la syntaxe . (point) sur un objet et la méthode append dont on oublie facilement le nom, ça devient compliqué pour un élève de 2nde qui ne pratique pas la programmation régulièrement et qui n'est pas initié à la programmation orientée objet.

Call_BB5A a écrit:
À côté de cela, l'élève qui entend "ajouter" pensera facilement à l'opération +.

et je trouve qu'il a beaucoup trop de pièges pour les débutants

Code:


>>> var=4
>>> print(var+"toto")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'


Flo44 a écrit:
Franchement, pour un débutant ? Quand le langage est fortement typé, tu commences par expliquer les types de données aux élèves. Quand il ne l'est pas, il devrait pouvoir se débrouiller pour les conversions de type, sans générer d'erreur incompréhensible pour un débutant... D'ailleurs pour ceux qui l'enseignent, notamment en seconde, vous faites comment?

Flo44 a écrit:
Et la gestion de l'indice des tableaux. Berk. (sans compter que ça n'a aucun sens, le nombre d'éléments ne correspond pas à celui de l'intervalle)

Flo44 a écrit:
Et l'absence de caractère de fin d'instruction (comment on fait pour faire une instruction sur plusieurs lignes? c'est peut-être possible, mais bon)

Flo44 a écrit:
Et, l'ultime horreur pour moi, le décalage qui remplace les accolades ou autres indicateurs de début ou fin de bloc. Non seulement, c'est illisible, mais si ton éditeur n'est pas spécialement conçu, si ton élève jongle entre les tabulations et les espaces, tu fais comment pour voir les erreurs et débugger son programme ?

Flo44 a écrit:
Il est vrai que je ne suis pas allée beaucoup plus loin, mais à côté de Perl ou Ruby, pour comparer les langages conçus dans le même but, "y'a pas photo ! ".

Simeon a écrit:

Flo44 a écrit:
Franchement, pour un débutant ? Quand le langage est fortement typé, tu commences par expliquer les types de données aux élèves. Quand il ne l'est pas, il devrait pouvoir se débrouiller pour les conversions de type, sans générer d'erreur incompréhensible pour un débutant... D'ailleurs pour ceux qui l'enseignent, notamment en seconde, vous faites comment?

Python est fortement typé, personnellement j'explique les types dès le départ, en prenant justement l'exemple du fait qu'additionner un nombre et une chaîne de caractère n'a pas de sens. En demandant de temps en temps de préciser les types, les élèves retiennent plutôt bien. Et franchement les langages qui te cast les trucs pour faire passer 4 + "toto", c'est juste l'horreur.


Même en langage C, tu auras un avertissement du compilateur. D'ailleurs, le langage C n'est pas très typé statiquement contrairement au C++ (d'ailleurs, c'est un excellent langage d'apprentissage). Python te permet de faire par exemple des additions de type "string" non voulues, certainement pas C++ (ni C) si tu programmes correctement, un tas d'erreurs non contrôlées passent en Python et on obtient parfois n'importe quoi sans en trouver la cause.
C'est l'éternel débat entre langage typé statiquement et dynamiquement, il existe d'ailleurs P++, un dérivé de PHP typé statiquement sur la demande de la communauté de programmeurs. Le débat est éternel

Flo44 a écrit:
Et la gestion de l'indice des tableaux. Berk. (sans compter que ça n'a aucun sens, le nombre d'éléments ne correspond pas à celui de l'intervalle)

Tu veux dire slice et indice négatif ? Ce n'est pas du tout au programme. (et je ne comprends pas la remarque sur le nbr d'éléments des intervalles, si on parle du range, ça correspond)

Bah si c'est au programme, et d'ailleurs présent dans un sujet zéro de NSI. Et effectivement une horreur car un indice, c'est un entier naturel à la base. On en a déjà parlé dans un topic précédent mais ta réponse avait été très différente.
Que dire de l'instruction a,b = b,a où les élèves croient que l'on "permute" simplement les données ...

Flo44 a écrit:
Et l'absence de caractère de fin d'instruction (comment on fait pour faire une instruction sur plusieurs lignes? c'est peut-être possible, mais bon)

\ est un caractère de continuation.
Ce n'est pas un problème par contre (selon moi).

Flo44 a écrit:
Et, l'ultime horreur pour moi, le décalage qui remplace les accolades ou autres indicateurs de début ou fin de bloc. Non seulement, c'est illisible, mais si ton éditeur n'est pas spécialement conçu, si ton élève jongle entre les tabulations et les espaces, tu fais comment pour voir les erreurs et débugger son programme ?

Le message d'erreur est plutôt clair dans ce genre de cas, et à moins de programmer avec notepad, l'éditeur gère les espaces correctement.
Pas mieux que Simeon.

Flo44 a écrit:
Il est vrai que je ne suis pas allée beaucoup plus loin, mais à côté de Perl ou Ruby, pour comparer les langages conçus dans le même but, "y'a pas photo ! ".

Je connais pas Perl car dès que j'ai eu l'occasion de voir 2 lignes de Perl, je me suis dit: WTF.
Mais tout ce que tu reproches à Python en dehors de l'indentation se retrouve dans Ruby. Ruby est fortement et dynamiquement typé, il n'accepte donc pas de 4 + "toto", il y a des indices négatifs et du slice avec .. très proche de celui de Python.

Simeon a écrit:Je dois dire que ça ne correspond pas du tout à mon expérience avec les élèves, truc.append est en général retenu assez facilement. Au passage les listes ne sont pas au programme de seconde.

Call_BB5A a écrit:À côté de cela, l'élève qui entend "ajouter" pensera facilement à l'opération +.

Il se ferait donc avoir par un faux ami.

Simeon a écrit:Python est fortement typé, personnellement j'explique les types dès le départ, en prenant justement l'exemple du fait qu'additionner un nombre et une chaîne de caractère n'a pas de sens.

Call_BB5A a écrit:
Dans ce cas pourquoi la multiplication d'une chaîne et d'un entier devrait en avoir ?

Call_BB5A a écrit:
Et donnez une valeur booléenne à un réel, une chaîne, une liste ? On encore permettre des opérations logiques comme : "" or 5 ?

Je ne dis pas que Python c'est mal, mais il possède des défauts pour un débutant.

kaktus65 a écrit:J'ai commencé par le C puis le C++ depuis plus de 20 ans. Après, Python, c'est quand même un bon choix lorsque l'on explique qu'il existe d'autres langages VRAIMENT typés (le typage dynamique, non merci) avec leurs avantages et inconvénients. Je crois que c'est le principal : tout langage de programmation est valable, après, chacun ses convictions.
Dire que Python est la panacée, c'est par contre un mensonge éhonté.

Rwan a écrit:

Code:


u_n = 1
repeter 50 000 fois
    u_n = 5 * u_n² - 5 * u_n
fin répéter


Tu préfères faire cet algo à la main, ou plutôt prendre 5 minutes pour l'implémenter et 1 seconde pour l'executer?

Prezbo a écrit:

Rwan a écrit:

Code:


u_n = 1
repeter 50 000 fois
    u_n = 5 * u_n² - 5 * u_n
fin répéter


Tu préfères faire cet algo à la main, ou plutôt prendre 5 minutes pour l'implémenter et 1 seconde pour l'executer?

Dans ce cas précis, ni l'un ni l'autre : on peut montrer par récurrence qu'à partir de la première exécution de la boucle, u_n=0.

Par ailleurs, utiliser u_n comme non de variable est plutôt maladroit et mène à une écriture horrible :

u_n = 5 * u_n² - 5 * u_n


Certes mais le "=" n'est pas l'égalité mathématique mais une affectation, ce qui n'a rien à voir.
Bon après, la suite présentée n'est en effet pas la plus intéressante  :sourit:

Il me semble là qu'il y a confusion entre la définition par récurrence d'une suite (u_n) en maths, auquel cas il faudrait écrire u_{n+1}=5 * u_n² - 5 * u_n, et le calcul des termes successifs de cette suite par un algorithme, auquel cas le programme n'a en mémoire à un moment donné que le dernier terme calculé, qu'il vaut mieux désigner par un nom sans indice comme u puisque l'indice varie justement à chaque étape...

Code:


x = range(3, 6)
for n in x:
  print(n)


Code:

>>> squares = []
>>> for x in range(10):
...    squares.append(x**2)
...
>>> squares
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

Flo44 a écrit:Comme je vous l'ai dit, Python j'ai essayé, mais comme je n'en ai finalement pas eu besoin, j'ai laissé tomber. Donc j'ai parlé de tableaux alors qu'il semblerait que je pensais plutôt aux listes. Bref. Voici ce que je supporte très mal :

Code:


x = range(3, 6)
for n in x:
  print(n)


Pour afficher les nombres de 1 à 5
Quand on a vu ça à l'Espe, tous les anciens développeurs de la salle ont été choqués. C'est totalement illogique (en tout cas ça va à l'encontre de tous les autres langages de programmation). Quand on donne un intervalle d'entier, on donne généralement le plus petit élément, et le plus grand...

Déjà, je n'aime pas trop les langages qui commencent leurs indices à zéro (vous comptez à partir de zéro, vous? vous prenez le 0-ième élément d'une liste?)

Code:

>>> squares = []
>>> for x in range(10):
...     squares.append(x**2)
...
>>> squares
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

Si on dit que c'est range(10), pour moi ça va de 1 à 10...
Mon cerveau ne doit pas être fait pour ça.

Mais peut-être qu'en fait je me trompe, et que les débutants ne sont pas dérangés par cela. Ou alors peut-être que vous n'utilisez jamais le parcours de liste avec les indices de position?

Flo44 a écrit:Comme je vous l'ai dit, Python j'ai essayé, mais comme je n'en ai finalement pas eu besoin, j'ai laissé tomber. Donc j'ai parlé de tableaux alors qu'il semblerait que je pensais plutôt aux listes. Bref. Voici ce que je supporte très mal :

Code:


x = range(3, 6)
for n in x:
  print(n)


Pour afficher les nombres de 1 à 5
Quand on a vu ça à l'Espe, tous les anciens développeurs de la salle ont été choqués. C'est totalement illogique (en tout cas ça va à l'encontre de tous les autres langages de programmation). Quand on donne un intervalle d'entier, on donne généralement le plus petit élément, et le plus grand...

Flo44 a écrit:
Déjà, je n'aime pas trop les langages qui commencent leurs indices à zéro (vous comptez à partir de zéro, vous? vous prenez le 0-ième élément d'une liste?)

C'est aussi en contradiction avec l'algorithmique que les élèves voient en Seconde où dans la phase d'initialisation (et à juste titre)

kaktus65 a écrit:

Prezbo a écrit:

Rwan a écrit:

Code:


u_n = 1
repeter 50 000 fois
    u_n = 5 * u_n² - 5 * u_n
fin répéter


Tu préfères faire cet algo à la main, ou plutôt prendre 5 minutes pour l'implémenter et 1 seconde pour l'executer?

Dans ce cas précis, ni l'un ni l'autre : on peut montrer par récurrence qu'à partir de la première exécution de la boucle, u_n=0.

Par ailleurs, utiliser u_n comme non de variable est plutôt maladroit et mène à une écriture horrible :

u_n = 5 * u_n² - 5 * u_n


Certes mais le "=" n'est pas l'égalité mathématique mais une affectation, ce qui n'a rien à voir.
Bon après, la suite présentée n'est en effet pas la plus intéressante  :sourit:

Il me semble là qu'il y a confusion entre la définition par récurrence d'une suite (u_n) en maths, auquel cas il faudrait écrire u_{n+1}=5 * u_n² - 5 * u_n, et le calcul des termes successifs de cette suite par un algorithme, auquel cas le programme n'a en mémoire à un moment donné que le dernier terme calculé, qu'il vaut mieux désigner par un nom sans indice comme u puisque l'indice varie justement à chaque étape...

Simeon a écrit:

Call_BB5A a écrit:
Dans ce cas pourquoi la multiplication d'une chaîne et d'un entier devrait en avoir ?

Parce qu'on ne peut pas additionner un scalaire et un vecteur, et que pourtant on peut multiplier un vecteur par un scalaire.

T'es quand même ultra exigeant sur ce que tu attends d'un langage, qu'est ce que tu proposes comme langage avec moins de défauts ? Parce que là, il doit à peine rester Ocaml, (Pascal) ou Haskell qui peuvent vaguement encore passer.

Flo44 a écrit:Comme je vous l'ai dit, Python j'ai essayé, mais comme je n'en ai finalement pas eu besoin, j'ai laissé tomber. Donc j'ai parlé de tableaux alors qu'il semblerait que je pensais plutôt aux listes. Bref. Voici ce que je supporte très mal :

Code:


x = range(3, 6)
for n in x:
  print(n)


Pour afficher les nombres de 1 à 5
Quand on a vu ça à l'Espe, tous les anciens développeurs de la salle ont été choqués. C'est totalement illogique (en tout cas ça va à l'encontre de tous les autres langages de programmation). Quand on donne un intervalle d'entier, on donne généralement le plus petit élément, et le plus grand...

Déjà, je n'aime pas trop les langages qui commencent leurs indices à zéro (vous comptez à partir de zéro, vous? vous prenez le 0-ième élément d'une liste?)

Code:

>>> squares = []
>>> for x in range(10):
...     squares.append(x**2)
...
>>> squares
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

Si on dit que c'est range(10), pour moi ça va de 1 à 10...
Mon cerveau ne doit pas être fait pour ça.

Mais peut-être qu'en fait je me trompe, et que les débutants ne sont pas dérangés par cela. Ou alors peut-être que vous n'utilisez jamais le parcours de liste avec les indices de position?

Code:


>>> squares = [ x**2 for x in range(10) ]
>>> squares
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]


Code:


>>> squares = ( x**2 for x in range(10) )
>>> squares.__next__()
0
>>> squares.__next__()
1
>>> squares.__next__()
4
>>> squares.__next__()
9
>>> squares.__next__()
16
>>> squares.__next__()
25
>>> squares.__next__()
36
>>> squares.__next__()
49
>>> squares.__next__()
64
>>> squares.__next__()
81
>>> squares.__next__()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration