Forum Prepas.org

Oui ça fait longtemps que numpy/scipy/matplotlib non seulement existent pour python3 mais c'est même la version de base depuis déjà longtemps.
Si on code proprement en 2.7 et qu'on ne manipule pas trop de chaines (utf8...) on ne verra pas la différence entre le 3.X et le 2.7.X....sauf sur la division de deux entiers...mais je déconseille fortement d’utiliser implicitement le fait que "int/int" renvoie float un python3 (et un int en python2).
Autre différence qu'on peut peut être voir : le type entier. en 2.7 on a des int puis des long quand ça devient trop grand. En 3, c'est UN seul et unique type entier. C'est plus propre car "changer de type quand on fait +1" bof bof niveau sémantique MAIS ça cache le fait qu'un int qui tiens sur 64 se traite beaucoup plus rapidement qu'un int qui ne tiens plus sur 64bits..

Ewind a écrit :Ta vidéo date de 2013.

Oui, 2013, l'année où a été introduit l'informatique en CPGE. À ce moment les modules nécessaires pour le calcul numérique n'étaient pas tous tout à fait au point pour la version 3.x.x (numpy pour Python3 date de 2010, mais matplotlib de 2012/2013 et encore cela ne fonctionnait pas toujours très bien sous Windows). De nombreux lycée ont donc fait le choix de la version 2.7, ce qui n'a pas nécessairement été changé depuis (et ce n'est pas forcément si simple que cela lorsque l'on a préparé (*) de nombreux supports/modules qu'il faut tous modifier).

Pour moi l'énorme avantage (**) de la version 3.x.x. c'est le choix de l'encodage UTF-8 par défaut, ce qui est quand même vraiment mieux lorsque l'on doit jongler entre différents systèmes d'exploitation et lire/ouvrir des fichiers.

Par contre je ne vois pas d'inconvénient à assumer que la division renvoie un flottant en python3 (de même que la racine carrée par exemple). Le but de ce changement c'est bien de se simplifier la vie. Il vaudrait mieux que tous les utilisateurs de 2.7 utilisent en préambule
(*) Dans l'idéal ces supports/modules auront été prévus dès le début pour être compatibles avec Python3, mais n'oublions pas que de très nombreux enseignants se sont formés sur le tas pour pouvoir mettre en place à cette réforme.

(**) Et aussi le fait de pouvoir utiliser des caractères unicode dans les noms de variable, pour le côté amusant.

Oui pour utf8 mais le mieux dans le cadre de la prepa est probablement de ne mettre que de l'ascii partout...même si ca fait vraiment old school.
Disons que pour la division le problème est de SAVOIR ce que ça fait. Comme il y a encore pas mal de python 2.7 dans le monde, on doit expliquer que ca a changé. Le préambule ok ok mais quand ce n'est pas ton code (dans la vraie vie) et que ce code est gros avec des import dans tous les sens...il n'est pas évident de savoir ce que va faire /.

Autre chose : le fait de renvoyer un float n'est pas anodin car ca interdit tout test avec == sur le résultat. Il faut faire passer ce message aux étudiants.

La racine carré? tiens ca a changé entre le 2 et le 3?
Ce dont je me rappelle (en 2 et??? en 3) c'est que sqrt n'est PAS la même fonction selon qu'on la prend de numpy, de scipy ou de python math...donc quand j'ai besoin de sqrt sur les complexe je relis la doc

fakbill a écrit :Disons que pour la division le problème est de SAVOIR ce que ça fait.

Je suis bien d'accord, mais le comportement de python3 est quand même bien plus clair justement (on utilise soit '\' pour les flottants soit '\\' pour les entiers, pas d'ambiguïté possible). En python2 lorsque l'on voit dans un code
on n'a aucun moyen de savoir vraiment ce qui va se passer et c'est donc assez problématique. Il faudrait soit systématiquement utiliser from __future__ import division, soit impérativement écrire partout
ou
même si la ligne précédente était b = sqrt(2).

En pratique, pour un étudiant travaillant sur python3, le seul problème qu'il pourrait rencontrer c'est copier/coller un code sous python2 qui utiliserait quelque part le fait que a / b est entier, ce qui ne devrait pas exister (il faudrait utiliser '//').

fakbill a écrit :Le préambule ok ok mais quand ce n'est pas ton code (dans la vraie vie) et que ce code est gros avec des import dans tous les sens...il n'est pas évident de savoir ce que va faire /.

Heu... Dans la "vraie vie" on ne devrait certainement pas aver des imports dans tous les sens... Les imports devraient être regroupés et structurés clairement en en tête de module et de toutes façon from __future__ import doit être la première chose rencontrée (et n'est valable (heureusement !) que dans le module en question). Je ne vois donc aucun moyen de se fourvoyer.

fakbill a écrit :Autre chose : le fait de renvoyer un float n'est pas anodin car ca interdit tout test avec == sur le résultat. Il faut faire passer ce message aux étudiants.

Oui, mais c'est aussi le cas avec '/' en python2 (qui ne devrait être utilisé que pour des divisions flottantes, même s'il est nécessaire de l'expliciter) en pratique.

fakbill a écrit :La racine carré? tiens ca a changé entre le 2 et le 3?

Je voulais dire que sqrt(4) n'est pas un entier.

On a un peu dévié du sujet initial...

Heu... Dans la "vraie vie" on ne devrait certainement pas aver des imports dans tous les sens... Les imports devraient être regroupés et structurés clairement en en tête de module et de toutes façon from __future__ import doit être la première chose rencontrée (et n'est valable (heureusement !) que dans le module en question). Je ne vois donc aucun moyen de se fourvoyer.

Heu oui mais tu sais...il y a des TONNES de codes très mal écrits dans la nature...je crois que tu sous estimes ce problème.

Sinon oui oui...c'est plus clair en python3 et heureusement

maht.sqrt(4) est un int en python2?? (je n'ai pas python sous la main pour vérifier): si oui c'était vraiment une connerie dans le design du langage.

fakbill a écrit :

maht.sqrt(4) est un int en python2?? (je n'ai pas python sous la main pour vérifier): si oui c'était vraiment une connerie dans le design du langage.

Non ! Bien sûr math.sqrt renvoie un flottant quoi qu'il arrive.

ha ouf...je ne pouvais pas croire que le BDFL laisse passer un truc pariel!