Comments on: Point rapide sur les types hints http://sametmax.com/point-rapide-sur-les-types-hints/ Du code, du cul Sat, 07 Nov 2015 11:08:18 +0000 hourly 1 http://wordpress.org/?v=4.1 By: Ludovic Gasc (GMLudo) http://sametmax.com/point-rapide-sur-les-types-hints/#comment-159822 Mon, 27 Apr 2015 19:45:15 +0000 http://sametmax.com/?p=16128#comment-159822 Salut Sam,

En ce qui concerne l’amélioration des performances, j’avais les mêmes espoirs que toi.

J’en avais discuté avec Guido au moment où il avait sorti ça, il m’avait dit que c’était peu probable.

J’en ai rediscuté avec des gens de PyPy pendant la PyCON-US, ils m’ont confirmé cet état de fait.

En fait, si j’ai bien tout suivi, un des problèmes, c’est que les types fournis dans ce module sont trop “high-level” par rapport aux types de base qu’utilisent PyPy, Cython & cie, tu n’as pas un matching 1-1, et donc soit tu dois quand même fournir des types + précis avec Cython, soit PyPy doit quand même faire du prédictive pour le JIT.

Après, ça ne serait pas la première fois que quelqu’un trouve une manière pour que ça serve à booster du code, alors que tout le monde pensait que c’était impossible. La communauté Python est quand même spécialisé dans la course à la + grosse, il n’y a qu’à voir toutes les pistes pour pouvoir optimiser du code en Python pour s’en convaincre ;-) Par exemple, ce n’est pas en Ruby que tu as tout cet arsenal.

]]>
By: matthieu http://sametmax.com/point-rapide-sur-les-types-hints/#comment-159814 Mon, 27 Apr 2015 16:24:23 +0000 http://sametmax.com/?p=16128#comment-159814 J’utilise déjà ce système (PyCharm le prend en compte avec Python 3.4, même si ce n’est pas aussi complet).

L’utiliser dans l’annotation a l’avantage d’avoir la complétion active et donc nettement plus pratique à utiliser. En revanche, ça pose des problèmes quand on a des références croisées (module1.fonction est utilisé dans module2, et prend des arguments de type module2.classe).

Je ne sais pas trop comment les résoudre proprement (ce qui m’a poussé à abandonner le truc).

En type hiniting, sachant que le import se fait automatiquement :

from mon.super.projet import maclasse

def mafonction(arg: maclasse):

[blabla]

Avec les docstring, tout doit être tapé à la main :

def mafonction(arg):

""" :type arg: :class:mon.super.projet.maclasse  (le :class: permet à sphinx de faire les liens)

"""

[balbla]

]]>
By: Zanguu http://sametmax.com/point-rapide-sur-les-types-hints/#comment-159808 Mon, 27 Apr 2015 14:20:48 +0000 http://sametmax.com/?p=16128#comment-159808 En ce moment j’ai un combo Symfony2 PhpStorm, j’use et abuse des @param et @var pour forcer l’autocomplétion.

Je peux toujours passer une string au lieu d’un int à ma fonction mais la signature fait pas trop lignes quand j’ai plus de 4 paramètres.

Du coup j’ai des comm tout le temps repliés qui prennent presque plus de place que le code

/**

* @param \Chemin\vers\entity $entity

* @param int $un_id

* @return JsonResponse

*/

function truc($entity, $un_id) {

/**

* @var \Chemin\vers\entityDeux $autre_entity

* @var \Chemin\vers\mon\objet\aLaCon $a_la_con

*/

return new JsonResponse([$autre_entity, $a_la_con]);

}

C’est moche, ça prend de la place, mais ça m’évite de taper n’importe quoi et quand je veux lire ma fonction pour voir si j’ai raté un truc, je les replie et c’est aussi lisible qu’avant.

J’aime bien aussi les annotation en C# aka “le triple slash” qui sert à documenter l’auto-complétion de VS et/ou sortir une doc complete.

Mais là en python, pour un truc censé être juste indicatif c’est vraiment moche.

]]>
By: LeMeteore http://sametmax.com/point-rapide-sur-les-types-hints/#comment-159807 Mon, 27 Apr 2015 14:12:20 +0000 http://sametmax.com/?p=16128#comment-159807 Je pense que cette fonctionnalité sera surtout utilisée par de grosses boites ayant besoin de contraintes fortes dans leurs pipelines de builds automatisés, etc. A mon tout petit niveau, j’attends, qui sait? Je m’en servirai peut etre :\

Je pense aussi que la syntaxe c’est pr ne pas trop s’eloigner de ce que font “les autres langages”, tu lis, et tu piges plus ou moins vite ce qui se passe (scala, java, haskell, …)

Mais oui, je trouve moi aussi que c’est moche :\ on verra bien où ça nous mene.

]]>
By: Eric http://sametmax.com/point-rapide-sur-les-types-hints/#comment-159801 Mon, 27 Apr 2015 12:12:34 +0000 http://sametmax.com/?p=16128#comment-159801 Il y avait une session interessante sur le sujet a l’europython 2014 par Bob Ippolito.

Il en ressortait que MyPy etait la “moins pire” des options pour verifier les types.

]]>
By: Romain http://sametmax.com/point-rapide-sur-les-types-hints/#comment-159797 Mon, 27 Apr 2015 10:42:33 +0000 http://sametmax.com/?p=16128#comment-159797 Mais quand même, putain c’est moche.

Ben, ça ressemble à du Scala quoi ^-^.

Ça a un aspect documentaire indéniable. Par contre, ça ouvre la porte à une étape de build qui va effectuer les contrôles, non ?

Ce qui est amusant c’est que ça arrive à un moment ou je lis pas mal de chose contre le typage dynamique…

Au final, pourquoi pas. C’est bien de laisser le choix au développeur de les utiliser ou pas.

]]>