Je suis assez d’accord avec toi, dans la théorie ; J’étais assez méfiant sur cette histoire de typage lorsque j’ai commencé à utiliser sérieusement Python. Toutefois depuis maintenant quelques années, je me suis rendu compte qu’en pratique j’ai rarement des problèmes liés au typage. Notons aussi que je fais du numérique, et que lorsque c’est nécessaire je peux quand même spécifier le type d’un tableau, et c’est ce qui m’importe (dtype=int32,float32,float64 et c’est à peu près tout). Du code numérique manipule assez peu de type en réalité, par contre il peut donner beaucoup de contrainte sur la taille, l’intervalle, la précision et l’étendue ainsi que sur les propriétés entre les nombres, toutes choses ne pouvant pas être vérifiés par un compilateur, et accessoirement pénible à gérer proprement (NaN&Co). Le type des variables à manipuler devient un « problème » négligeable et le b.a-ba de tout programmeur numérique, parce qu’une formation mathématique t’apprends nécessairement à bien définir ce que sont tes variables, avant même de réfléchir à une implémentation.
La doc c'est bien joli mais comme ce n'est pas pris en compte par le langage
C’est une approche typiquement pythonesque que de dire que le programmeur sait ce qu’il fait, et de rester très souple concernant le langage lui même (typage, pas de protection dans les classes, etc.). Qu’on aime ou pas, je ne dirai pas ce que ça donne sur un gros projet en équipe, mais pour du code à soi, j’ai constaté que toutes ces vérifications de type sont peu utiles et les erreurs liées sont tout aussi vite corrigées dans un code Python. J’ai même acquis la conviction que ça encourage la bonne pratique de bien réfléchir à l’avance à ses structures de données.
Et pour moi, il est hors de question de vérifier, par exemple qu’un vecteur qui arrive à l’entrée d’une fonction est normalisé, c’est au programmeur qui fait appel à la fonction de vérifier ça. Pour des raisons de performances comme tu le dis... plus par habitude qu’autre chose, parce que de toute façon Python est d’une lenteur effroyable...
Pour les inférences de type, je n’ai jamais utilisé, donc je ne peux pas dire ce que ça donne en pratique, mais pourquoi pas.
[^] # Re: J'aimerais
Posté par BB . En réponse au journal Votre langage idéal ?. Évalué à 3.
Je suis assez d’accord avec toi, dans la théorie ; J’étais assez méfiant sur cette histoire de typage lorsque j’ai commencé à utiliser sérieusement Python. Toutefois depuis maintenant quelques années, je me suis rendu compte qu’en pratique j’ai rarement des problèmes liés au typage. Notons aussi que je fais du numérique, et que lorsque c’est nécessaire je peux quand même spécifier le type d’un tableau, et c’est ce qui m’importe (dtype=int32,float32,float64 et c’est à peu près tout). Du code numérique manipule assez peu de type en réalité, par contre il peut donner beaucoup de contrainte sur la taille, l’intervalle, la précision et l’étendue ainsi que sur les propriétés entre les nombres, toutes choses ne pouvant pas être vérifiés par un compilateur, et accessoirement pénible à gérer proprement (NaN&Co). Le type des variables à manipuler devient un « problème » négligeable et le b.a-ba de tout programmeur numérique, parce qu’une formation mathématique t’apprends nécessairement à bien définir ce que sont tes variables, avant même de réfléchir à une implémentation.
C’est une approche typiquement pythonesque que de dire que le programmeur sait ce qu’il fait, et de rester très souple concernant le langage lui même (typage, pas de protection dans les classes, etc.). Qu’on aime ou pas, je ne dirai pas ce que ça donne sur un gros projet en équipe, mais pour du code à soi, j’ai constaté que toutes ces vérifications de type sont peu utiles et les erreurs liées sont tout aussi vite corrigées dans un code Python. J’ai même acquis la conviction que ça encourage la bonne pratique de bien réfléchir à l’avance à ses structures de données.
Et pour moi, il est hors de question de vérifier, par exemple qu’un vecteur qui arrive à l’entrée d’une fonction est normalisé, c’est au programmeur qui fait appel à la fonction de vérifier ça. Pour des raisons de performances comme tu le dis... plus par habitude qu’autre chose, parce que de toute façon Python est d’une lenteur effroyable...
Pour les inférences de type, je n’ai jamais utilisé, donc je ne peux pas dire ce que ça donne en pratique, mais pourquoi pas.