Juste pour préciser mon point de vue : je pense que le typage statique est une excellente chose, et je regrette vraiment que Python n'y attache pas plus d'importance. Et pas seulement pour des raisons d'efficacité...
Juste pour préciser une chose: hormis pour des raisons d'efficacité, je pense que le typage statique tend à créer plus de problèmes qu'il n'en résouds - particulièrement avec un système de type déclaratif à la Java
Plus de problème que ceux posés par l'absence totale de typage ? Tu as quelques exemples ?
Oh la jolie question à flame-war ;-)
Tu a remarqué aussi ?-)
Je saute dedans: d'abord - je pense que tu le sais mais je préfère préciser - il n'y a pas "absence totale de typage" en Python.
Mmm... On pourrait aussi considérer qu'il n'existe en fait en Python qu'un seul et unique type, le type 'object' - ce qui revient peu ou prou à une absence de type !-)
Il n'y a juste ni déclarations, ni inférence de type. Mais tous les objets Python connaissent leur type
s/type/classe/
et génèreront une erreur s'ils ne sont pas utilisés correctement.
ce qui n'est pas nécessairement lié à la classe de l'objet - vu qu'on peut dynamiquement ajouter / supprimer / remplacer n'importe quel attribut/méthode d'une instance.
Accessoirement, une des (rares) erreur de typage qui m'ait posé problème dans une appli Python (dont je n'étais pas l'auteur, et dont le code était supposé valide) était dû au passage d'une chaine au lieu d'une liste de chaines. Les deux étant des itérables, et le code de la fonction appelée ne faisant appel à aucune méthode (ou attribut) spécifique d'une liste, le bug ne générait pas d'erreur (exception) à l'exécution (mais produisait bien sûr un résultat incorrect, ce qui est bien plus gênant).
Ceci étant, et même si les tests unitaires étaient un peu complexes à mettre en oeuvre vu le contexte (gestion des perms dans une appli Plone), l'auteur aurait dû vérifier au moins manuellement ce point dès l'écriture du code (c'est en tous cas ce que j'aurais personnellement fait) au lieu d'assumer que tout allait bien en l'absence d'exception.
Par contre, ce sera une erreur à l'exécution; ça, je comprend que ça puisse être un problème.
Les conséquences d'une erreur d'exécution sont (en gérénal) potentiellement moins gravissimes en Python qu'en C (ah, les UB...)
Cela dit, compte tenu du fait que le typage statique ne peut en aucun cas garantir
En tous cas pas à lui seul...
la correction de ton code, de toutes façons, tu vas devoir faire des tests unitaires pour les fonctionnalités que tu implémentes.
Qui ne garantissent pas non plus à eux seuls la correction du code.
(snip le reste - globalement d'accord).
Eric Brunel a écrit :
Alain Ketterlin wrote:
Bruno Desthuilliers <bruno.42.desthuilliers@websiteburo.invalid> writes:
Juste pour préciser mon point de vue : je pense que le typage statique
est une excellente chose, et je regrette vraiment que Python n'y attache
pas plus d'importance. Et pas seulement pour des raisons d'efficacité...
Juste pour préciser une chose: hormis pour des raisons d'efficacité,
je pense que le typage statique tend à créer plus de problèmes qu'il
n'en résouds - particulièrement avec un système de type déclaratif à
la Java
Plus de problème que ceux posés par l'absence totale de typage ? Tu as
quelques exemples ?
Oh la jolie question à flame-war ;-)
Tu a remarqué aussi ?-)
Je saute dedans: d'abord - je pense que
tu le sais mais je préfère préciser - il n'y a pas "absence totale de typage"
en Python.
Mmm... On pourrait aussi considérer qu'il n'existe en fait en Python
qu'un seul et unique type, le type 'object' - ce qui revient peu ou prou
à une absence de type !-)
Il n'y a juste ni déclarations, ni inférence de type. Mais tous les
objets Python connaissent leur type
s/type/classe/
et génèreront une erreur s'ils ne sont pas
utilisés correctement.
ce qui n'est pas nécessairement lié à la classe de l'objet - vu qu'on
peut dynamiquement ajouter / supprimer / remplacer n'importe quel
attribut/méthode d'une instance.
Accessoirement, une des (rares) erreur de typage qui m'ait posé problème
dans une appli Python (dont je n'étais pas l'auteur, et dont le code
était supposé valide) était dû au passage d'une chaine au lieu d'une
liste de chaines. Les deux étant des itérables, et le code de la
fonction appelée ne faisant appel à aucune méthode (ou attribut)
spécifique d'une liste, le bug ne générait pas d'erreur (exception) à
l'exécution (mais produisait bien sûr un résultat incorrect, ce qui est
bien plus gênant).
Ceci étant, et même si les tests unitaires étaient un peu complexes à
mettre en oeuvre vu le contexte (gestion des perms dans une appli
Plone), l'auteur aurait dû vérifier au moins manuellement ce point dès
l'écriture du code (c'est en tous cas ce que j'aurais personnellement
fait) au lieu d'assumer que tout allait bien en l'absence d'exception.
Par contre, ce sera une erreur à l'exécution; ça, je
comprend que ça puisse être un problème.
Les conséquences d'une erreur d'exécution sont (en gérénal)
potentiellement moins gravissimes en Python qu'en C (ah, les UB...)
Cela dit, compte tenu du fait que le typage statique ne peut en aucun cas
garantir
En tous cas pas à lui seul...
la correction de ton code, de toutes façons, tu vas devoir faire des
tests unitaires pour les fonctionnalités que tu implémentes.
Qui ne garantissent pas non plus à eux seuls la correction du code.
Juste pour préciser mon point de vue : je pense que le typage statique est une excellente chose, et je regrette vraiment que Python n'y attache pas plus d'importance. Et pas seulement pour des raisons d'efficacité...
Juste pour préciser une chose: hormis pour des raisons d'efficacité, je pense que le typage statique tend à créer plus de problèmes qu'il n'en résouds - particulièrement avec un système de type déclaratif à la Java
Plus de problème que ceux posés par l'absence totale de typage ? Tu as quelques exemples ?
Oh la jolie question à flame-war ;-)
Tu a remarqué aussi ?-)
Je saute dedans: d'abord - je pense que tu le sais mais je préfère préciser - il n'y a pas "absence totale de typage" en Python.
Mmm... On pourrait aussi considérer qu'il n'existe en fait en Python qu'un seul et unique type, le type 'object' - ce qui revient peu ou prou à une absence de type !-)
Il n'y a juste ni déclarations, ni inférence de type. Mais tous les objets Python connaissent leur type
s/type/classe/
et génèreront une erreur s'ils ne sont pas utilisés correctement.
ce qui n'est pas nécessairement lié à la classe de l'objet - vu qu'on peut dynamiquement ajouter / supprimer / remplacer n'importe quel attribut/méthode d'une instance.
Accessoirement, une des (rares) erreur de typage qui m'ait posé problème dans une appli Python (dont je n'étais pas l'auteur, et dont le code était supposé valide) était dû au passage d'une chaine au lieu d'une liste de chaines. Les deux étant des itérables, et le code de la fonction appelée ne faisant appel à aucune méthode (ou attribut) spécifique d'une liste, le bug ne générait pas d'erreur (exception) à l'exécution (mais produisait bien sûr un résultat incorrect, ce qui est bien plus gênant).
Ceci étant, et même si les tests unitaires étaient un peu complexes à mettre en oeuvre vu le contexte (gestion des perms dans une appli Plone), l'auteur aurait dû vérifier au moins manuellement ce point dès l'écriture du code (c'est en tous cas ce que j'aurais personnellement fait) au lieu d'assumer que tout allait bien en l'absence d'exception.
Par contre, ce sera une erreur à l'exécution; ça, je comprend que ça puisse être un problème.
Les conséquences d'une erreur d'exécution sont (en gérénal) potentiellement moins gravissimes en Python qu'en C (ah, les UB...)
Cela dit, compte tenu du fait que le typage statique ne peut en aucun cas garantir
En tous cas pas à lui seul...
la correction de ton code, de toutes façons, tu vas devoir faire des tests unitaires pour les fonctionnalités que tu implémentes.
Qui ne garantissent pas non plus à eux seuls la correction du code.
(snip le reste - globalement d'accord).
William Dode
On 29-07-2009, Alain Ketterlin wrote:
William Dode writes:
Personnellement, je trouve que le typage statique permet plus de vérification du compilateur et que ça c'est bien pour le programmeur pour corriger du code plus facilement.
Franchement je pense que c'est un faux problème. Car soit on se fout complètement de vérifier le type, par exemple si on fait une boucle for i in range(10), soit on s'inquiète du type pour un tas de raisons, par ex éviter un sql injection, hors dans ce cas le type ne suffira généralement pas, il faudra surement vérifier d'autres choses. Que l'entier est compris entre telles et telles valeurs, qu'une chaine ne contient pas de guillemets etc... Ce sont des cas beaucoup plus fréquents, il vaut mieux ne pas perdre de temps avec les déclarations inutiles et utiliser ce temps pour des vérifications réellement complètes.
Ce que tu évoques n'a effectivement rien à voir avec le typage, c'est de la validation de données.
C'est bien ce que je voulais montrer, on confond souvent les deux. Hors on voudrait souvent faire croire que la vérification de type suffit à valider une donnée... Comme Bruno, j'ai constaté que les bugs de type sont extrêmement rares, en revanche les bugs à cause d'un manque de validation sont très courants on n'y coupe pas, type déclaré ou pas.
Heu, sinon c'est quoi "l'inférence de type" ? L'explication sur Wikipédia n'est pas très claire.
Le compilateur va deviner tout seul le type d'une variable d'un bout à l'autre du code et faire les vérifications en conséquence. Du coup on a un peu l'avantage des deux, pas de déclaration mais une vérification automatique. C'est aussi ce que doit faire le JIT pour un morceau de code j'imagine.
Non, ça n'a rien à voir avec le JIT.
Souvent si, regarde le nombre de papiers qui l'évoquent sur la page d'unladen : http://code.google.com/p/unladen-swallow/wiki/RelevantPapers
Une recherche sur google confirme également que la plupart des jit le font.
-- William Dodé - http://flibuste.net Informaticien Indépendant
On 29-07-2009, Alain Ketterlin wrote:
William Dode <wilk@flibuste.net> writes:
Personnellement, je trouve que le typage statique permet
plus de vérification du compilateur et que ça c'est bien
pour le programmeur pour corriger du code plus facilement.
Franchement je pense que c'est un faux problème. Car soit on se fout
complètement de vérifier le type, par exemple si on fait une boucle for
i in range(10), soit on s'inquiète du type pour un tas de raisons, par
ex éviter un sql injection, hors dans ce cas le type ne suffira
généralement pas, il faudra surement vérifier d'autres choses. Que
l'entier est compris entre telles et telles valeurs, qu'une chaine ne
contient pas de guillemets etc... Ce sont des cas beaucoup plus
fréquents, il vaut mieux ne pas perdre de temps avec les déclarations
inutiles et utiliser ce temps pour des vérifications réellement
complètes.
Ce que tu évoques n'a effectivement rien à voir avec le typage, c'est
de la validation de données.
C'est bien ce que je voulais montrer, on confond souvent les deux. Hors
on voudrait souvent faire croire que la vérification de type suffit
à valider une donnée... Comme Bruno, j'ai constaté que les bugs de type
sont extrêmement rares, en revanche les bugs à cause d'un manque de
validation sont très courants on n'y coupe pas, type déclaré ou pas.
Heu, sinon c'est quoi "l'inférence de type" ? L'explication
sur Wikipédia n'est pas très claire.
Le compilateur va deviner tout seul le type d'une variable d'un bout
à l'autre du code et faire les vérifications en conséquence. Du coup on
a un peu l'avantage des deux, pas de déclaration mais une vérification
automatique. C'est aussi ce que doit faire le JIT pour un morceau de
code j'imagine.
Non, ça n'a rien à voir avec le JIT.
Souvent si, regarde le nombre de papiers qui l'évoquent sur la page
d'unladen :
http://code.google.com/p/unladen-swallow/wiki/RelevantPapers
Une recherche sur google confirme également que la plupart des jit le
font.
--
William Dodé - http://flibuste.net
Informaticien Indépendant
Personnellement, je trouve que le typage statique permet plus de vérification du compilateur et que ça c'est bien pour le programmeur pour corriger du code plus facilement.
Franchement je pense que c'est un faux problème. Car soit on se fout complètement de vérifier le type, par exemple si on fait une boucle for i in range(10), soit on s'inquiète du type pour un tas de raisons, par ex éviter un sql injection, hors dans ce cas le type ne suffira généralement pas, il faudra surement vérifier d'autres choses. Que l'entier est compris entre telles et telles valeurs, qu'une chaine ne contient pas de guillemets etc... Ce sont des cas beaucoup plus fréquents, il vaut mieux ne pas perdre de temps avec les déclarations inutiles et utiliser ce temps pour des vérifications réellement complètes.
Ce que tu évoques n'a effectivement rien à voir avec le typage, c'est de la validation de données.
C'est bien ce que je voulais montrer, on confond souvent les deux. Hors on voudrait souvent faire croire que la vérification de type suffit à valider une donnée... Comme Bruno, j'ai constaté que les bugs de type sont extrêmement rares, en revanche les bugs à cause d'un manque de validation sont très courants on n'y coupe pas, type déclaré ou pas.
Heu, sinon c'est quoi "l'inférence de type" ? L'explication sur Wikipédia n'est pas très claire.
Le compilateur va deviner tout seul le type d'une variable d'un bout à l'autre du code et faire les vérifications en conséquence. Du coup on a un peu l'avantage des deux, pas de déclaration mais une vérification automatique. C'est aussi ce que doit faire le JIT pour un morceau de code j'imagine.
Non, ça n'a rien à voir avec le JIT.
Souvent si, regarde le nombre de papiers qui l'évoquent sur la page d'unladen : http://code.google.com/p/unladen-swallow/wiki/RelevantPapers
Une recherche sur google confirme également que la plupart des jit le font.
-- William Dodé - http://flibuste.net Informaticien Indépendant
