Journal MyPy 0.3 sort bien accompagné

Posté par  . Licence CC By‑SA.
Étiquettes :
22
19
fév.
2016

MyPy permet d'ajouter du typage statique à Python tout en restant compatible.
La version 0.3 est compatible avec la PEP 484

Guido fait maintenant parti des développeurs de MyPy (avec d'autres employés de Dropbox), le dépôt est sous l'arborescence python sur github. C'est dire l'importance qu'est entrain de prendre ce projet.

Pour l'instant la page du projet met surtout en avant l'intérêt en terme de debug et maintenance, mais parions que cela peut également donner des pistes pour améliorer les performances…

La PEP insiste pour confirmer que Python restera un langage dynamique et que les auteurs n'ont aucune envie de le rendre obligatoire, même par convention.

Annonce : http://mypy-lang.blogspot.fr/2016/02/mypy-03-released.html
Site : http://www.mypy-lang.org/
Pep : https://www.python.org/dev/peps/pep-0484/
Dépôt : https://github.com/python/mypy

  • # C'est intégré dans Python 3.5

    Posté par  . Évalué à 1.

    Python 3.5 possède le type hinting :
    https://docs.python.org/3/whatsnew/3.5.html#whatsnew-pep-484

    Le projet mypy est l'inspiration de cette fonctionnalité. D'ailleurs Guido a pas mal bossé avec Jukka Lehtosalo.

    • [^] # Re: C'est intégré dans Python 3.5

      Posté par  (site web personnel) . Évalué à 4.

      Je trouve que ce travail autour du type hinting dans Python révèle une forme de schizophrénie assez amusante, surtout quand on lit ça dans la PEP

      Instead, it is assumed that a separate off-line type checker (e.g. mypy) will be used for on-demand source code analysis.

      Le côté offline me fait un peu rire, car c'est par nature incompatible avec le côté dynamique de Python. Petit exemple tiré par les cheveux :

      file1.py

import builtins 
builtins.int= float
import file2

      et son copaing

      def foo(a: int):
    return a

      un analyseur /offline/ verra a comme un int, mais à l'exécution, l'annotation pointera sur le /builtin/ float. L'expérience Pythran [0](http://pythonhosted.org/pythran] m'a convaincu que toute approche statique avec Python sera bâtarde. Pylint et consort me laissent d'ailleurs le même goût dans la bouche, « pas dans l'esprit » :-/

      • [^] # Re: C'est intégré dans Python 3.5

        Posté par  (site web personnel) . Évalué à 4.

        C'est sûr qu'on trouvera toujours des cas tirés par les cheveux (ou pas), qui mettent à mal le type hinting, l'inférence de type, et toutes ces notions issues du typage statique.

        Parfois, ces choses (qui ne sont pas possibles avec un langage à typage statique) sont bien pratiques, nous sommes d'accord. Cependant, je suis persuadé qu'il est possible de les limiter à quelques cas bien précis et bien délimités, avec 99% du code qui pourrait être en typage statique (avec toutes les garanties que cela apporte).
        En tout cas, c'est comme ça que j'essaie de construire mon code, ça augmente certes le nombre de variables (vu que je me force à ne pas utiliser des types différents avec la même variable) mais ça augmente la sécurité (vu que l'inférence de type de Pycharm fonctionne beaucoup mieux).

        • [^] # Re: C'est intégré dans Python 3.5

          Posté par  . Évalué à 3.

          On trouve aussi l'inverse où on triche avec un langage à typage statique… Y a pas de miracle ! C'est pour ça que je trouve intéressant ce consensus où on essaye maintenant d'apporter plus de souplesse dans les langages statiques et plus de "sécurité" dans les langages dynamiques.

          • [^] # Re: C'est intégré dans Python 3.5

            Posté par  . Évalué à 2.

            Plus de souplesse dans les langages statiques? Tu penses à quoi?

            • [^] # Re: C'est intégré dans Python 3.5

              Posté par  . Évalué à 2.

              Je pense au Go par exemple, les interfaces, l'inférence de type, la compilation quasi instantanée…

              • [^] # Re: C'est intégré dans Python 3.5

                Posté par  . Évalué à 3.

                C'est pas souple l'inference de type, ca t'evite juste de taper le nom du type partout, mais sinon ca reste toujours le meme typage rigide

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                • [^] # Re: C'est intégré dans Python 3.5

                  Posté par  . Évalué à 3.

                  Pas vraiment d'accord, il a raison: dans certains cas tu changes le type de retour d'une fonction et tu n'as pas besoin de changer l'appelant car il utilise l'inférence de type, donc cela peut etre considere comme une souplesse.
                  Après le "maintenant" c'est plutôt vieux l'inférence de type..
                  Et je ne vois pas le rapport avec la compilation rapide, au contraire c'est plutôt grâce à un typage 'simpliste'(pas de génériques??) que Go est rapide a compiler..

            • [^] # Re: C'est intégré dans Python 3.5

              Posté par  . Évalué à 2. 

                  dynamic

              en C# par exemple.

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # Python est bien vivant

    Posté par  (site web personnel) . Évalué à 3.

    Avec la transition (assez longue) vers Python 3, quelques Cassandre avaient prédit la fin de Python.
    On voit qu'au contraire, le langage est bien vivant. C'est d'ailleurs un des langages interprétés avec le plus d'implémentations concurrentes.
    Certes, les versions Java (Jython) et C# (IronPython) sont mortes, mais on se retrouve avec quelques projets qui sont bien vivants :

    • cpython, la version historique,
    • pypy (autre implémentation),
    • brython (implémentation en JS),
    • cython (pour compiler un surensemble de Python)
    • nuitka (autre compilateur Python),
    • pyjion (un JIT pour cpython),
    • pyston (implémentation par Dropbox utilisant LLVM),
    • numba (compilateur orienté vers le calcul scientifique).

    C'est également le signe que pas mal de gens attendent plus de perfs de la part de cpython, pour l'utiliser dans des domaines pour lesquels il n'était pas prévu à la base, avec deux problèmes qui reviennent fréquemment : la gestion de la mémoire et le GIL (global interpreter lock, qui empêche d'utiliser à fond plusieurs coeurs).

Suivre le flux des commentaires

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