Journal [MyFirstPython, nouveau projet ?]Le python c'est bien mangez-en !!

Posté par djibb (site web personnel) le 18 avril 2013 à 15:33. Licence CC By‑SA.

Étiquettes : aucune

avr.

2013

Oui, je sais, ce titre est un appeau à trolls.

Contexte : Les élèves de classes de CPGE auront 2h d'enseignement obligatoire d'informatique par semaine à partir de l'année prochaine.
Le langage choisi a été Python. Il n'est pas question ici de discuter ce choix :il est déjà acté.
Ceci implique, dans le cadre de l'enseignement de l'ISN en terminale, que les choix pédagogiques concernant le langage (java/processing/ ou Python) qui étaient plutôt laissé libres au bon vouloir des profs vont, pour des raisons d'unicité et de cohérence, s'orienter franchement vers le Python.

Disclaimer : je suis prof de physique, autodidacte en informatique, j'ai programmé 2-3 projets uniquement Python dont le plus connu et le plus utilisé est pymecavideo. (il y a aussi pyfocus et livespectra, au point mort tous les deux)
Donc, autant dire que Python est un langage que j'aime bien et que je pratique un peu.

Le problème : lors de mon enseignement de la programmation en ISN, je me suis rendu compte que Python n'était pas la panacée pour un premier langage. Son plus gros ~~avantage~~ inconvénient étant son typage dynamique non explicite.

Pour les élèves non pratiquants, la notion de typage devient alors très vite très vague et "mais m'sieur ça marche…". Les messages très compréhensibles (aucune ironie) du style :
"cannot concatenate 'str' and 'int' object" deviennent un vrai problème même après 6 heures de TP, de lectures et d'essais-erreurs.

De l'autre côté, Python a plein des bons côtés : ils produisent du code propre (merci l'indentation), font assez rapdiment des choses intéressantes et s'approprient assez vite l'outil.

Le projet : je souhaiterais mettre en place une surcouche à python qui oblige à une déclaration des variables et de leurs types.
Ceci permettra non seulement aux élèves de préciser l'organisation de leur pensée fonctionnelle mais aussi à réfléchir de manière plus simple à la portée de leurs variables.

J'ai déjà préparé un début de carte mentale sur le cahier des charges.
J'ai un peu cherché et n'ai pas vu de projets permettant ceci. Quelqu'un a peut-être cela en stock.

Je cherche donc des pythoneux qui seraient intéressés pour se lancer dans l'aventure.
contact : ashashiwa chez gougueul toussa.

# Glossaire

Posté par CHP le 18 avril 2013 à 15:37. Évalué à 10.

Pour ceux qui sont comme moi, j'ai fait la recherche :
CPGE : Classe Préparatoire aux Grandes Ecoles
ISN : informatique et sciences numériques
# Pourquoi faire simple quand on peut faire compliqué ?

Posté par Strash le 18 avril 2013 à 15:52. Évalué à 5.

Je comprends pas la démarche. Pour avoir été élève de CPGE, je sais bien que les personnes dans ces classes ne sont pas idiotes. La première fois qu'ils vont se retrouver avec une erreur de type "cannot concatenate 'str' and 'int' object", ils vont poser une question. La prochaine fois ils vont lire le texte d'erreur et comprendre leur erreur.

Expliquez-moi quelle est la différence :
- Il est écris en toute lettre quelque part dans le programme que la variable "a" est du texte et "b" est un nombre
- On a un typage dynamique de deux variables "a" et "b" et l'une contient du texte, l'autre un nombre

Dans les deux cas lorsqu'on va essayer bêtement de les concaténer, on va avoir une erreur.

Pour l'utiliser souvent pour de petits calculs, parsing, etc… Python est un langage très agréable a utiliser, clair, facile à lire quand on se replonge dans un vieux code, et qui a l'immense avantage d'avoir des variables non typées.

Pourquoi vouloir à tout prix transposer vos sales notions de types figés de variables à un langage tel que python ?
Python n'est pas assez L33T pour vous ?

Si les élèves veulent se destiner à des études les amenant à apprendre à programmer dans d'autres langage, ils auront largement de quoi apprendre ce qu'est une variable typée. Sinon laissez les hors de tout ça !
- [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
  
  Posté par Marc Cousin le 18 avril 2013 à 16:10. Évalué à 10.
  
  Avant de commencer, je préfère préciser que je fais le plus gros de mes devs en perl, et que donc je fais aussi beaucoup de non-typé.
  
  Malgré tout, pour beaucoup de contextes, avoir un langage fortement typé, ça a de gros avantages. Le principal étant de détecter beaucoup d'erreurs dès la compil, et pas uniquement quand le programme passe dans le bout de code qui pose problème.
  
  C'est donc pas une question d'être L33T ou autre. Ça a des avantages réels. Et je pense qu'il vaut mieux commencer sur du fortement typé, prendre les bonnes habitudes au départ, quitte à passer sur des langages plus laxistes sur ce sujet après. Mais bon, on va pas refaire le monde, Python a été choisi (et oui, malgré ma préférence pour Perl, je pense qu'il vaut encore mieux débuter en Python, Perl pouvant faire beaucoup plus de dégâts dans des mains inexpérimentées :) ). D'mon temps, on leur faisait faire du Pascal sur des 286, aux élèves de «CPGE», ma bonne dame :)
  - [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
    
    Posté par Strash le 18 avril 2013 à 16:23. Évalué à 6.
    
    Un élève de CPGE n'a pas (dans la grande majorité) pour vocation de devenir un programmeur. Je pense qu'il est très intéressant pour eux d'avoir une introduction à la programmation, afin de comprendre les notions d'algorithmes et l'aide que peux fournir l'outil informatique dans la démarche scientifique (au passage je trouve que 2h par semaine est beaucoup trop). Mais leur premier objectif est tout de même de passer des concours extrêmement difficiles dans de multiples matières scientifiques. C'est beau de vouloir leur montrer la "bonne voie" mais ils n'ont pas de temps de cerveau à consacrer à tout ces détails.
    
    Pour ce qui est des erreurs pendant la compil ou pendant l'exécution, cela m'étonnerais fortement que les élèves de CPGE produisent des programmes pour lesquels cela aurait une quelconque importance…
    
    De mon temps les cours d'informatique en CPGE se faisaient sous Maple/Mathématica, et (autant que je m'en souvienne) aucun de ces deux langages n'a de variables typées.
    - [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
      
      Posté par Thom (site web personnel) le 18 avril 2013 à 19:36. Évalué à 2.
      
      Tu oublies sans doute tous les étudiants qui ensuite feront des grandes études scientifiques comme à l'ENS, ceux qui retourneront à la fac après pour réaliser un doctorat, au hasard, en informatiques, en calcul scientifique par exemples. Alors, oui, les ingénieurs, commerciaux n'ont pas peut-être pas tous des soucis de coder de manière artistique, mais ce n'est pas non plus le seul débouché de ces prépas et certains d'entre eux peuvent très bien tombé amoureux de l’informatique.
      
      La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
    - [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
      
      Posté par neil le 18 avril 2013 à 20:29. Évalué à 9. Dernière modification le 18 avril 2013 à 20:32.
      Le Caml (dans sa version Light) est un langage typé couramment utilisé en CPGE, depuis près de 20 ans en MP/MPSI. Pour les étudiants qui font aussi des mathématique, il est très intéressant d’avoir un langage fortement typé et fonctionnel, puisque que c’est ce qui se rapproche le plus des mathématiques, et permet donc d’établir des liens (donc plus simple à mémoriser) en faisant des comparaisons rapidement. Par exemple, en Haskell la syntaxe des types est très compréhensible pour un étudiant qui fait des maths :
      
      c :: Float -> Float c r = 2 * pi * r
      
      Qu’on peut rapprocher de :
      
      c : ℝ → ℝ c (r) = 2 × π × r
      
      En fait le typage, et les liens qu’il défini avec la théorie des catégories en fait un excellent complément à un cours de maths, et permet de renforcer mutuellement les acquis dans les deux domaines. La rigueur et la précision qui en découle me semble être vitaux pour des étudiants qui aspirent à des carrières plus ou moins proche de la science et des mathématiques.
      
      Maplab et Mathematica sont des jolis outils quand on veut vérifier des gros calculs symboliques, mais les utiliser pour faire de l’informatique est non seulement un détournement de leurs fonctions, un problème éthique vu qu’ils sont non-libres, et ne va pas aider les étudiants à passer les concours.
  - [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
    
    Posté par Jean B le 19 avril 2013 à 00:05. Évalué à 2.
    
    avoir un langage fortement typé, ça a de gros avantages.
    Ça tombe bien Python à un typage fort. Dynamique (on ne déclare pas le typage d'une variable et il peut changer) mais fort (aucune coercion implicite).
    
    Le principal étant de détecter beaucoup d'erreurs dès la compil, et pas uniquement quand le programme passe dans le bout de code qui pose problème.
    
    Justement, ça ce discute, mais je pense comme d'autre qu'executer le programme jusqu'à tomber sur une erreur est parfois mieux pour des débutants, étant donné que ça accélère la boucle d'essai-erreur.
    
    À tout hasard personne n'a entendu parlé d'une étude sur les langages d'initiation ?
- [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
  
  Posté par jben le 18 avril 2013 à 16:50. Évalué à 10. Dernière modification le 18 avril 2013 à 16:51.
  Je comprends pas la démarche. Pour avoir été élève de CPGE, je sais bien que les personnes dans ces classes ne sont pas idiotes. La première fois qu'ils vont se retrouver avec une erreur de type "cannot concatenate 'str' and 'int' object", ils vont poser une question. La prochaine fois ils vont lire le texte d'erreur et comprendre leur erreur.
  
  Oh que non.
  
  J'ai enseigné des TP Info en Maple en prépa. Lorqu'on ne termine pas la ligne par un ; on a le droit à un message Unexpected end of input. Antant dire que c'est une erreur fréquente.
  - Les dix premières fois (pour chaque élève) on explique calmement.
  - Les dix fois suivantes (pour chaque élève) on explique.
  - Les dix fois suivantes on répond juste Rajoutez un ;.
  - Les dix fois suivantes on répond ;.
  Bien entendu, le même élève était capable de poser plusieurs fois la question dans la même séance.
  
  À la fin de l'année, environ la moitié a compris que quand on oubliait le ; on avait le droit à ce message d'erreur.
  - [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
    
    Posté par Xishu le 18 avril 2013 à 17:13. Évalué à 3.
    
    J’ai envie d’ajouter qu’à un élève qui ne comprend un message d’erreur aussi simple, je souhaiterais juste d’avoir d’autres talents pour rattraper sa moyenne à un niveau suffisant.
    Et aussi de comprendre qu’il doit s’orienter vers un autre domaine que l’informatique, même si «il y a des débouchés».
    
    Et non, même pas vers l’informatique «avec un niveau de responsabilité fonctionnel», vraiment ailleurs.
    - [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
      
      Posté par Thom (site web personnel) le 18 avril 2013 à 19:29. Évalué à 3. Dernière modification le 18 avril 2013 à 19:29.
      
      Je trouve la critique du bête élève sortant de terminal un peu facile. Car, les élèves qui arrivent en CPGE n'ont pour la plupart jamais touché de près comme de loin à la programmation. Il faut quand même se rappeler que la programmation en terminal même S, c'était encore sur calculette dans un style imbitable.
      
      Alors, oui, mettre un ; en fin de phrase ne se fait pas tout seul. Chercher à comprendre ses erreurs et ce qui ne va pas, non plus. Mais même ailleurs, il n'y a pas grands monde qui va lire les logs quand un logiciel plante. Ça demande plus que du temps, ça demande de l'implication.
      
      Mais, ça s’apprend, c'est même pour ça qu'est fait l'école. D'ailleurs, qu'il fasse des maths, de la physique ou de la bio, son niveau d'informatiques qu'il va acquérir va réellement être déterminant quant à son boulot plus tard qui, quoi qu'il se passe demanderont des compétences d'informatiques assez poussées.
      
      Puis franchement, prendre l'exemple de Maple comme langage de programmation, c'est typiquement un langage pour ne pas apprendre la programmation, j'ai un vague souvenir des nops() et autres atrocités.
      
      La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
      - [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
        
        Posté par jben le 18 avril 2013 à 20:32. Évalué à 8.
        
        Maple est pourri, je suis d'accord. Mais je réagissais uniquement sur le fait de comprendre et d'assimiler un message d'erreur. Et bien ça, ça ne rentre pas.
        
        Le message d'erreur est clair une fois qu'on a compris la cause de l'erreur. Il est absolument normal que l'élève demande, c'est moins normal qu'il demande encore à la dernière séance Monsieur, j'ai une erreur Unexpected end…, alors que tu l'as répété à toutes les séances et que je l'écrivais même au tableau en début de séance.
        
        Après il ne faut pas perde de vue que la programmation en prépa, c'est utile pour intégrer l'X ou les concours sur la banque Centrale. Si tu vises d'autre concours, et bien la séance d'info, c'est juste un truc qui te fait chier (et par transitivité qui fait chier ceux qui ne s'en foutent pas, et qui fait chier l'enseignant, j'ai été successivement dans les deux cas, je sais de quoi je parle).
  - [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
    
    Posté par ZankFrappa le 21 avril 2013 à 22:30. Évalué à 2.
    
    Et ça ne te choque pas que des élèves a priori plus intelligents que la moyenne, à qui on essaye de donner une certaine rigueur scientifique (le premier objectif des cours de maths et de physique étant de les associer à enchaîner les cycles de définitions/propriétés/théorèmes), soient incapables de comprendre le caractère systématique du code Maple ? Franchement, des élèves qui sont capables de comprendre (avec quelques exercices) une définition axiomatique des nombres réels (comme « unique corps totalement ordonné doté de la propriété de la borne supérieure, à isomorphisme près ») ne devraient pas avoir autant de mal à apprendre à programmer. L'informatique est mal enseignée, et les objets étudiés (notamment Maple — mais vraisemblablement Python aussi) sont mal construits.
    - [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
      
      Posté par djibb (site web personnel) le 21 avril 2013 à 23:26. Évalué à 2.
      
      clap clap… c'est ça…
    - [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
      
      Posté par jben le 21 avril 2013 à 23:41. Évalué à 6.
      
      des élèves qui sont capables de comprendre […] une définition
      
      Bien justement, une critique reccurente envers les classes préparatoires (critique que je partage), est que comprendre n'est que secondaire après apprendre. Et c'est apprendre des modes de résolutions d'exercice, apprendre des mode de résolutions de problèmes, etc. La compréhension et l'interprétation des notions n'est pas assez valorisé à mon sens.
      
      Ce qu'il y a de drole, c'est que les sujets des ÉNS sont souvent vu comme très durs. Techniquement ils sont durs, mais pas hors de porté, mais ils demandent de réflechir differement et de ne pas se contenter des modes classique de reflexion.
      
      Après je n'ai pas dit que les classes prépa étaient une mauvaise chose, je n'en sais rien, mais il faut à tout prix que les élèves qui sont passés par là sachent sortir de ce qu'on leur a appris.
      
      Enfin pour revenir au sujet de l'info dans le classes prépa, le plus gros problème c'est l'interet je pense. Comme toutes les banques d'epreuves n'en tienne pas compte, il y a des élève qui en ont rien à foutre.
      - [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
        
        Posté par reno le 22 avril 2013 à 16:17. Évalué à 1.
        
        Ce qu'il y a de drole, c'est que les sujets des ÉNS sont souvent vu comme très durs. Techniquement ils sont durs, mais pas hors de porté,
        
        Hum je me souviendrai toute ma vie d'avoir été dans le premier quart avec un brillant 4/20 en maths! (Note étant obtenue par: je résous le I 1) a), mince je n'arrive pas à faire le I 1 b) donc je résous le II 1) a) etc..).
        
        Pour toi ce n'est peut-être pas "hors de porté" mais les 2 gars que je connaissais qui sont entrées à l'ENS avaient un point commun: ils "planaient"! Correspondant assez bien à la caricature: très, très fort en math mais un peu perdu dans la vie quotidienne..
        
        [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
        
        Posté par jben le 22 avril 2013 à 18:05. Évalué à 5.
        
        les 2 gars que je connaissais qui sont entrées à l'ENS avaient un point commun: ils "planaient"! Correspondant assez bien à la caricature: très, très fort en math mais un peu perdu dans la vie quotidienne.
        
        Merci pour le compliment. Mais pour ma part (étant passé par une ÉNS), j'ai besoin de me droguer pour planer, et me débrouille très bien dans la vie quotidienne.
        
        Je peux aussi te parler des X que j'ai connu, oui j'en ai rencontré dans la caricature des X, d'autres non, et certains sont des gens avec qui j'ai plaisir à intéragir. Je te prie donc de garder tes préjugés pour toi.
# le python a un typage dynamique

Posté par matteli le 18 avril 2013 à 15:55. Évalué à 7.

Si python a été choisi, c'est certainement pour de bonnes raisons ;-)
Le typage dynamique du python est une de ses caractéristiques, pourquoi vouloir le changer ? Dans ce cas, ce n'est plus du python et il vaut mieux changer de langage (ce qui n'est pas possible).
Je ne suis pas sur que si les étudiants ne comprennent pas "cannot concatenate 'str' and 'int' object", ils y arriveront avec une déclaration explicite du type.

Tu peux leur faire mettre en commentaire le type de chaque variable à la première déclaration. Ca les sensibilisera au type des variables, tout en conservant la philo du python.
- [^] # Re: le python a un typage dynamique
  
  Posté par Xishu le 18 avril 2013 à 16:11. Évalué à 2.
  
  Une surcouche de typage statique, je ne dit pas que ça n’est pas réalisable, mais je pense que ça représente beaucoup de travail pour, au final, retirer à Python un de ses points forts. De plus, les élèves formée avec cette techno particulière ne pourrait pas directement utiliser leurs connaissance pour écrire du code en vrai Python. Ça serait dommage de ne pas leur donner les moyens de contribuer.
  
  En plus de la solution à base de commentaire proposé ci-dessus, je suggère d’inciter les élèves à utiliser le mot-clé type dans un print, pour qu’il comprennent quels objets ils manipulent. Une analogie dans le monde matériel donnerait : «Une même boite peut contenir plusieurs sortes d’objets, à vous de coller la bonne étiquette dessus pour vous y retrouver».
- [^] # Re: le python a un typage dynamique
  
  Posté par Dreammm le 18 avril 2013 à 16:50. Évalué à 3.
  
  Si python a été choisi, c'est certainement pour de bonnes raisons ;-)
  
  La principale raison du choix de python, c'est la librairie matplotlib, qui permet à l'instar de matlab de faire des math et d'obtenir des jolies courbes.
  
  Il ne faut pas oublier que l'informatique dans les classes prépas, c'est avant tout pour faire l'application de problèmes scientifiques, et d'arriver à voir que les maths peuvent servir à quelque chose.
  - [^] # Re: le python a un typage dynamique
    
    Posté par oao le 19 avril 2013 à 01:21. Évalué à 3.
    
    Il ne faut pas oublier que l'informatique dans les classes prépas, c'est avant tout pour faire l'application de problèmes scientifiques, et d'arriver à voir que les maths peuvent servir à quelque chose.
    
    Pas pour tout le monde, l'option MP-Info fait des vrais maths théoriques avec application sur Caml.
- [^] # Re: le python a un typage dynamique
  
  Posté par djibb (site web personnel) le 18 avril 2013 à 18:53. Évalué à 1.
  
  Il n'y a pas trop à revenir sur le typage dynamique. Par contre, souligner les changements de types d'une variable, faire un point sur qui est quoi en cours d'utilisation peut être très intéressant.
  
  Je me contrefiche des performances. Par contre, le but dujeu est d'être le plus pédagogique possible et d'aider les élèves dans la construction de leurs compétences.
  - [^] # Re: le python a un typage dynamique
    
    Posté par wilk le 22 avril 2013 à 14:29. Évalué à 1.
    
    qui est quoi en cours d'utilisation
    …
    Je me contrefiche des performances. Par contre, le but du jeu est d'être le plus pédagogique possible
    
    Dans ce cas, qu'est-ce que ça changerait que le type soit vérifié à la compilation ou à l'exécution ?
    C'est un peu comme si tu voulais enseigner l'orthographe avec un correcteur orthographique !
# quel est le type de données que je manipule ?

Posté par palm123 (site web personnel) le 18 avril 2013 à 15:59. Évalué à 4.

Apprends leur quelques commandes comme
type(x)
dir(x)
help(x)

Pré-installe un interpréteur Python comme
bpython ou Ipython
si cela existe dans l'environnement utilisé

Ok je []

ウィズコロナ
- [^] # Re: quel est le type de données que je manipule ?
  
  Posté par djibb (site web personnel) le 18 avril 2013 à 18:40. Évalué à 1.
  
  et qu'est-ce que tu crois qu'on fait "à la première utilisation de python" ?
  
  Bien sûr que l'on voit cela, de long en large et en travers.
  
  Mais le fait d'avoir plus d'erreurs ou d'indication permet de se construire une représentation plus vite.
# class property

Posté par THE_ALF_ le 18 avril 2013 à 16:07. Évalué à 1.
Pour avoir un "vrai" typage, ça va être dur directement, car tu peut toujours faire du "a = quelquechose" qui va t'effacer l'ancien a, quoiqu'il arrive.

Le moyen le plus simple est d'utiliser les property des classes:
```
class Tint(object):
    def __init__(self, val):
        self.data = val
    @property
    def data(self):
        return self._data
    @data.setter
    def data(self,val):
        if type(val) is int:
            self._data = val
        else:
            raise TypeError("Donne un entier")

>>> a =Tint(3)
>>> print a.data
3
>>> a.data = 4
>>> print a.data
4
>>> a.data = 4.1
(...)
TypeError: Donne un entier
>>> a.data += 3
>>> print a.data
7
>>> a.data += 4.2
(...)
TypeError: Donne un entier
>>> a.data += "toto"
TypeError: unsupported operand type(s) for +=: 'int' and 'str'
>>> b = Tint(3.2)
TypeError: Donne un entier
```
Pas parfait, mais surement le plus simple.
- [^] # Re: class property
  
  Posté par THE_ALF_ le 18 avril 2013 à 16:16. Évalué à 2.
  A tiens, notes que si tu peux avoir une classe plus généraliste qui prends n'importe quel type de départ, mais interdit par la suite les changement:
```
class Typed(object):
    def __init__(self, val):
        self._data = val
    @property
    def data(self):
        return self._data
    @data.setter
    def data(self,val):
        if type(val) is type(self._data):
            self._data = val
        else:
            raise TypeError("Donne un "+str(type(self._data)))
```
  - [^] # Re: class property
    
    Posté par feth le 18 avril 2013 à 21:40. Évalué à 3.
    
    Je suis vraiment pas convaincu, mais je dis ça en dehors de toute pédagogie à des informaticiens grands débutants.
    Spontanément, face à "cannot concatenate…", j'aurais tendance à dégainer l'endroit où l'erreur est produite par Python, dir() et autres outils d'introspection pour montrer que ça aurait pu fonctionner, mais en fait non.
    - [^] # Re: class property
      
      Posté par THE_ALF_ le 18 avril 2013 à 22:18. Évalué à 1.
      
      Certes, mais prends en compte que c'est juste un exemple écris en 30 seconde pour montrer le principe.
      
      A mon avis, c'est une méthode intéressante à utiliser lorsque l'on veut être sur du type d'une variable, et être sur que celui-ci ne change pas en cours d'exécution (éviter par exemple qu'une variable contenant un float se voit au bout d'un moment transformée en int, et donner des résultats "bizarre" lorsqu'on l'utilise dans certaines divisons, en tout cas avec Python 2).
      
      Pour une implémentation plus propre et avoir des messages d'erreurs plus cohérents, il faudrait aussi surcharger les opérateurs d'addition, etc., pour gérer correctement les "mixs" de type. Encore une fois, c'est just un proof of concept pour avoir des variables fortement typée d'une manière raisonnablement propre.
      
      Pour ce qui est de l'intérêt pédagogique de l'exemple, et serait-ce bon à utiliser avec des étudiants, je demanderai un joker, par contre :p
      - [^] # Re: class property
        
        Posté par feth le 19 avril 2013 à 10:36. Évalué à 4.
        
        Ce qui ne me convainc pas, c'est l'intérêt de forcer un type. Alors que le ducktyping, c'est pas si compliqué ; je dirais même que c'est très concret : si ça ne fonctionne pas, c'est que quelque part, ça ne s'emboîte pas, pas à cause de la lutte des classes :-)
# Si Python3...

Posté par lolop (site web personnel) le 18 avril 2013 à 16:20. Évalué à 9.
Tu peux utiliser des annotations pour les paramètres et la valeur de retour d'une fonction.

http://www.python.org/dev/peps/pep-3107/

Ensuite, un décorateur @typecheck (et le script qui va avec) devrait faire l'affaire.

http://code.activestate.com/recipes/572161-method-signature-type-checking-decorator-for-pytho/

(je te recopie l'exemple d'utilisation donné dans la recette)
```
@typecheck
def foo(i: int) -> bool:
    return a > 0

@typecheck
def to_int(*, s: by_regex("^[0-9]+$")) -> int:
    return int(s)

@typecheck
def set_debug_level(self, level: optional(one_of(1, 2, 3)) = 2):
    self._level = level

This recipe is extensible with callable predicates, such as

is_even = lambda x: x % 2 == 0

@typecheck
def multiply_by_2(i: int) -> is_even:
    return i * 2
```
Si tu n'es qu'en Python2, une autre recette est donnée dans la discussion à la fin de la page:
http://code.activestate.com/recipes/426123-method-signature-checking-decorators/

Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Peut-être... revoir les messages d'erreur

Posté par lolop (site web personnel) le 18 avril 2013 à 16:26. Évalué à 2.

"cannot concatenate 'str' and 'int' object" deviennent un vrai problème

Je n'ai jamais regardé jusqu'où on pouvait hacker l'environnement interactif, mais si tu peux intercepter les erreurs et les rendre plus explicites (genre le message aussi en français, et avec quelques indications en plus…), ça serait pas mal pour les élèves.

Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
- [^] # Re: Peut-être... revoir les messages d'erreur
  
  Posté par CHP le 18 avril 2013 à 16:39. Évalué à 7.
  
  Je n'ai jamais regardé jusqu'où on pouvait hacker l'environnement interactif, mais si tu peux intercepter les erreurs et les rendre plus explicites (genre le message aussi en français, et avec quelques indications en plus…), ça serait pas mal pour les élèves.
  
  Ca me parait être une très mauvaise idée.
  
  Un jour en stage, un collègue (stagiaire lui aussi) avait totalement francisé sont linux. Il est allé voir son tuteur en lui demandant "c'est quoi un tuyau cassé ?"… Grosse incompréhension. Ce n'est qu'après qu'on a compris qu'il parlait d'un "broken pipe".
  
  Traduire (ou meme modifier) les messages d'erreurs, c'est rendre impossible le googlage de cette erreur.
  
  Et puis on parle de gens qui sont censé comprendre un anglais d'un niveau assez basique. S'il y a quelque chose qu'il ne comprennent pas dans "cannot concatenate 'str' and 'int' object", ca sera "concatenate", et dans ce cas ils ne comprendront pas non plus "concaténer".
  - [^] # Re: Peut-être... revoir les messages d'erreur
    
    Posté par lolop (site web personnel) le 19 avril 2013 à 09:45. Évalué à 3.
    
    Il ne faut en effet surtout pas retirer le message d’origine. C'est pour ça que j'avais écrit «message aussi en français, et avec quelques indications en plus…». L’idée serait plutôt de donner des pistes, genre "Vérifiez que la donnée stockée dans la variable x est bien du type désiré." — bon, c’est typiquement la piste que donnera le chargé de TP.
    
    Au niveau googlage des erreurs, ils ont accès au web extérieur lors de leurs travaux pratiques ?
    
    Tiens, je viens de voir que certains messages d’erreur sur les types avaient changé, pour y="5"+2:
    Python 3.2.3
    Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: Can't convert 'int' object to str implicitly
    
    Et Python 2.7.3
    Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: cannot concatenate 'str' and 'int' objects
    
    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
- [^] # Re: Peut-être... revoir les messages d'erreur
  
  Posté par karteum59 le 22 avril 2013 à 12:09. Évalué à 1.
  
  Localiser le langage de programmation promet de franches rigolades pour le travail collaboratif et le partage de code :)
# Cython ?

Posté par akimatsumoto le 18 avril 2013 à 18:41. Évalué à -1.

Je peux me tromper mais c'est ce que fait cython, ona la possibilité de typer les variables afin de le rendre plus rapide (Génération de module en C derrière)
Par contre on complique la génération du programme
- [^] # Re: Cython ?
  
  Posté par Batchyx le 18 avril 2013 à 19:24. Évalué à 3.
  
  Cython est un traducteur vers CPython. Ça ne type aucune variable python, ça permet plutôt de mélanger des variables python (autrement dit, des PyObject*) et des variables C.
  - [^] # Re: Cython ?
    
    Posté par akimatsumoto le 18 avril 2013 à 19:46. Évalué à -1.
    
    De toute façon, apres avoir jeter un coup d'oeil, ce n'est pas la panacée. Si le fait de ne pas avoir de variable typées pose pb pour ces étudiants, je pense que le fait de devoir mélanger les variables plus le fait de devoir compiler le code issu de cython risque de devenir très problématique. En plus on pers l'interet de l'interpréteur.
# Ici, on est déjà vendredi alors je peux

Posté par Maclag le 18 avril 2013 à 20:06. Évalué à 5.

Le langage choisi a été Python. Il n'est pas question ici de discuter ce choix :il est déjà acté.

Rappelle le couillon du ministère (expression piquée à un ancien prof de maths) qui a décidé ça, et dis-lui de (re-)mettre du OCaml. Tes problèmes de typage dynamique seront résolus!

En plus, tu pourras proposer à tous les étudiants d'installer Mldonkey… comme cas d'étude hein! Bien entendu!!
- [^] # Re: Ici, on est déjà vendredi alors je peux
  
  Posté par Gabbro le 18 avril 2013 à 23:56. Évalué à 2.
  
  Sauf que le-dit couillon du ministère, il avait mis du Caml et non du OCaml, ce qui fait que passé le concours, l'étudiant était certain de ne jamais réutiliser le langage appris. Avec OCaml, ça aurait été très probable, mais pas certain !
  - [^] # Re: Ici, on est déjà vendredi alors je peux
    
    Posté par Shuba le 19 avril 2013 à 08:35. Évalué à 7.
    
    l'étudiant était certain de ne jamais réutiliser le langage appris
    
    Honnêtement, on s'en fiche! Un élève qui sort de prépa n'arrive pas directement sur le marché du travail, il arrive en école d'ingé ou à l'université, et s'il avait choisi l'option MP-Info il est probable qu'il continue à faire de l'informatique. Ce sera dans un langage différent, mais c'est tant mieux, ça permet d'appréhender le fait qu'il n'y a pas qu'un seul paradigme de programmation. Ça permet aussi de ne pas considérer les idiosyncrasies du langage qu'on a appris comme étant un comportement normal.
    - [^] # Re: Ici, on est déjà vendredi alors je peux
      
      Posté par Gabbro le 19 avril 2013 à 15:55. Évalué à 1.
      
      Je répondais humouristiquement au message d'au dessus qui disait de remettre Caml. Celui-ci n'est plus utilisé en dehors des prépa et autant que je sache, plus soutenu.
      
      Quand aux paradigmes, OCaml étant impératif/fonctionnel/objet, pas de soucis. Pour les idiosyncrasies, depuis que je fais du python, je ne peut plus coder en C++.
# Je ne suis pas tout seul...

Posté par flan (site web personnel) le 18 avril 2013 à 22:23. Évalué à 3.

…à vouloir un Python avec typage statique.

Peut-être peut-on faire une surcouche à la machine virtuelle, pour faire de l'inférence de type à la OCaml.

Peut-être cela pourrait-il t'intéresser : http://www.mypy-lang.org
- [^] # Re: Je ne suis pas tout seul...
  
  Posté par GuiBrother le 19 avril 2013 à 22:38. Évalué à 1.
  J'ai utilisé des méthodes basés sur les "property" ou sur la surcharge de "__setitem__" pour typer un peu plus "statiquement" les variables.
  J'ai une classe qui s'initialise ainsi :
```
i = Data('i', int, 1)
```
  et s'utilise ainsi :
```
print i.value # affiche 1
print i() # idem
i = Data('i', int, 'a')
#-> erreur
i.value = 'a'
#-> erreur
```
  Ceci étant généralement encapsulé dans un dico en lecture seule et créé par la lib et non l'utilisateur.
```
params["nit"].value = 1 #ok
params["nit"].value = 'a' #erreur car mauvais type
params["nit"] = 'a' # erreur car lecture seule
```
  Grâce à ce typage, je suis certain par exemple qu'une division donnera le bon résultat même si l'utilisateur a oublié un point.
  Ça permet aussi d'envoyer des message d'erreur plus compréhensif (en français par exemple) et lors de la création de la variable et non lors de l'utilisation.
  Ça permet aussi d'imposer certains types ce qui permet de réduire le nombre de cas à gérer dans la bibliothèqe.
  Et plein d'autres petits avantages.
  
  Je n'utilisais néanmoins cette approche que pour les paramètres utilisateurs, tout le reste du code est typé dynamiquement pour profiter des avantages associés.
  
  Sinon il y a Enthought/Traits qui fait du typage statique.
# tests unitaires

Posté par wilk le 20 avril 2013 à 16:57. Évalué à 1.

Même si tu spécifie les types ça n'enlèvera rien au problème pédagogique de ne pas vérifier ce qui rentre et sort. Le type statique c'est surtout pour la pédagogie du compilateur. Pour le programmeur ça n'est qu'une erreur pas plus courante qu'une autre.

Quel est la différence entre 5 + "a" et datetime(123,32,201) ?
La première pourrait éventuellement être détecté à la compilation, mais la deuxième non. Alors pourquoi ajouter une technique qui vérifiera la première mais pas la deuxième ?
En revanche avec des tests unitaires on vérifiera aussi bien la deuxième (la plus courante !) que la première. Pédagogiquement c'est d'une pierre deux coups et ça marche avec n'importe quel langage.
- [^] # Re: tests unitaires
  
  Posté par Blackknight (site web personnel, Mastodon) le 20 avril 2013 à 20:56. Évalué à 5. Dernière modification le 20 avril 2013 à 20:57.
  
  Quel est la différence entre 5 + "a" et datetime(123,32,201) ?
  La première pourrait éventuellement être détecté à la compilation, mais la deuxième non. Alors pourquoi ajouter une technique qui vérifiera la première mais pas la deuxième ?
  
  Sauf qu'avec un typage statique, y a tout une série de tests unitaires que tu n'a pas besoin d'écrire, tout ceux où tu devras vérifier comment se comporte ton code quand l'utilisateur de ton code rentre un caractère à la place d'un chiffre.
  Pour ce qui est de datetime(123,32,201), dans certains langages, cela ne compilerait même pas, les valeurs étant hors plage d'emblée.
# Autre reptile tubulaire écailleux

Posté par potate le 21 avril 2013 à 02:58. Évalué à 2.

Pour info, j'ai par hasard pris connaissance de Cobra, un langage inspiré très fortement de Python pour la plateforme .Net. Il permet entre autre un typage statique (optionnel). Pour les différences avec Python, voir la page dédiée.
Après je ne me risquerai pas à le conseiller, je ne l'ai jamais utilisé et il n'est pas encore en version stable.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.