unladen-swallow

On 29-07-2009, Francois wrote:

William Dode a écrit :

Quand je tape "python mon_script.py"

D'abord 1) un compilateur compile le source "mon_script.py"
en bytecode et 2) ce bytecode est interprété par la machine
virtuelle Python. C'est bien ça ?

Mais le compilateur dont il est question dans 1), ce n'est
pas un JIT justement ? Ou alors le JIT est un autre
compilateur qui intervient dans l'étape 2) (au moment de
l'interprétation du bytecode) pour à nouveau compiler
certaines partie du bytecode en langage machine, c'est ça ?
Du coup, avec un JIT, il y aurait alors deux phases de
compilation ?

Tout juste. La première compilation en bytecode écrit sur disque (le
.pyc) tandis que la deuxième, le jit c'est en mémoire, d'où le terme 'in
time'.

D'accord. Merci bien. Juste une remarque, le .pyc n'est pas
toujours sur le disque mais en mémoire RAM également il me
semble, non ? C'est quand le code est un module que le .pyc
est copié sur le disque. Enfin je crois.

Je crois que tu crois bien. On pourra donc bientôt dire que python à un
double JIT !

--
William Dodé - http://flibuste.net
Informaticien Indépendant

On 29-07-2009, Alain Ketterlin wrote:

William Dode <wilk@flibuste.net> writes:

On 29-07-2009, Alain Ketterlin wrote:

[...] Je ne serai donc pas étonné qu'on nous parle bientôt de typage
statique dans Python, au-delà des annotations qui apparaissent dans
P3.

C'est un peu déjà ce qui est fait avec shedskin, pyrex, cython... A mon
avis pareil, on n'y coupera pas, mais tant que ça restera en option ce
n'est pas très gênant.

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é...

C'est excellent mais seulement quand on en a besoin. Par contre quand on
n'en a pas besoin la lourdeur annule les gains... Rester simple quand on
veut faire simple et pouvoir faire compliqué que si on a vraiment
besoin.

En tout cas il me semble que c'est la première fois qu'il y a autant de
boulot en cours focalisé sur les perfs de python. Je ne sais pas si ça
me servira souvent mais en tout cas c'est passionnant à suivre !

Tu as parfaitement résumé le dilemme : dans un script qui passe 90% de
son temps à attendre des entrées sorties, le gain sera négligeable s'il
est perceptible. Et j'ai l'impression que les gens qui font du calcul
avec python ont déjà passé tout ce qui est long en C. Mais quand c'est
google qui a besoin de quelque chose...

Le problème avec les extensions en C c'est qu'il faut les recompiler
à chaque changement de version, à chaque changement d'architecture etc.
Pour la maintenance c'est quand même royal d'avoir tout en Python pur.

--
William Dodé - http://flibuste.net
Informaticien Indépendant

Francois <francois@noSpam.fr> writes:

C'est bien cela. Le point important est que c'est une machine virtuelle
(un programme comme un autre) qui joue le rôle de... machine : cett e MV
doit donc interpéter une à une les instructions du bytecode, f ournir une
zone de mémoire, une pile d'exécution, etc.

Oui, c'est vraiment comme une machine dont le code machine est le
bytecode. De telles machines existent elles pour de vrai, je veux dire
physiquement ?

Sun avait voulu le faire pour Java mais a laissé tomber, et (bien) ava nt
eux on pouvait acheter des Lisp-Machines, avec un processeur spécialis é
pour Lisp. Il y a deux raisons principales pour lesquelles cela a peu de
chance d'exister.

La première est qu'un processeur c'est bien, mais qu'il faut aussi
écrire un système d'exploitation et toutes les applications. J'es père
que je ne choquerai la susceptibilité de personne en disant qu'un os en
python a peu de chance d'être à la hauteur.

La seconde est que le bytecode est une abstraction, aussi destinée à  
faciliter le portage. De plus, c'est un compromis entre le temps passé à
compiler et le temps passé à exécuter. Par exemple, la plupa rt des
machines virtuelles utilisent une pile, mais les machines réelles ont
depuis longtemps abandonné et sont passées aux registres. Il est plus
facile de compiler pour une machine à pile que pour une machine à
registre, mais pour les performances c'est dans l'autre sens.

-- Alain.

Bruno Desthuilliers <bruno.42.desthuilliers@websiteburo.invalid> writes:

Juste pour préciser mon point de vue : je pense que le typage stati que
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 ?

(après, si tu penses inférence de type, c'est un autre dé bat).

Effectivement, mais syntaxe de base et fonctions standards en Python
n'offrent pas assez d'informations pour ça. Ce serait déjà b ien qu'on
ait quelque chose pour vérifier quand c'est possible (en gros, dans mon
code, je peux faire confiance au reste).

-- Alain.

On 29-07-2009, Francois wrote:

Bruno Desthuilliers a écrit :

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
(après, si tu penses inférence de type, c'est un autre débat).

Ça serait possible d'avoir quelques explications.

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.

Par contre pour le compilateur c'est assez pratique de connaitre le type
à l'avance, mais là aussi il y a mieux. Plutôt que de tout déclarer tout
le temps, autant déclarer d'avantages de renseignements et juste là où
c'est chaud. Par exemple déclarer que telle fonction va être appelée
plein de fois, que tel tableau ne va jamais changer de taille etc.

Bref, rester simple quand c'est simple et compliqué seulement quand
c'est nécessaire. Et surtout ne pas croire que parce que c'est compliqué
c'est automatiquement plus sûr ! (genre java c'est bien pour les gros
projets et python pour les scripts...).

Es-tu d'accord avec ceci ?

Tu parlais peut-être "d'efficacité" dans le sens rapidité
d'exécution peut-être ?

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.

--
William Dodé - http://flibuste.net
Informaticien Indépendant

Francois <francois@noSpam.fr> writes:

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 (après, si tu penses inférence de type, c'est un autre
débat).

Je me permets de répondre à la place de Bruno.

Personnellement, je trouve que le typage statique permet plus de
vérification du compilateur et que ça c'est bien pour le progra mmeur
pour corriger du code plus facilement.

C'est le but. Ca évite surtout d'écrire une grande quantité de tests
pour "vérifier" chaque morceau de code (je mets des guillemets parce q ue
bien sûr il est impossible de tout vérifier avec des tests).

Tu parlais peut-être "d'efficacité" dans le sens rapidité d'exécution
peut-être ?

Un programme bien typé statiquement est en général plus effi cace parce
qu'il y a moins de choix à faire à l'exécution. Par exemple, si tu écris
a+b, à l'exécution l'interpréteur python doit aller chercher la
définition de l'opérateur + dans la classe de a (je choisis l'exe mple à
dessein parce qu'en fait c'est plus compliqué que cela). Avec le typag e,
il saurait d'entrée qu'il s'agit de la méthode __add__ de ma clas se
Machin (après avoir vu le code qui précède).

Heu, sinon c'est quoi "l'inférence de type" ? L'explication sur
Wikipédia n'est pas très claire.

Le compilateur examine le code pour déterminer les types impliqué s. Les
constantes et les opérations/fonctions étant typées, tu peux peu à peu
calculer l'ensemble des types impliqués, et vérifier que tout est
cohérent. Le programmeur ne mentionne aucun type, mais le typage est
fait par le compilateur.

C'est pas possible en python, à cause de la résolution dynamique des
noms: par exemple, la fonction

def f(par):
return glob+par

peut très bien avoir divers types au cours de l'existence du script. P ar
exemple :

glob = 1
print f(1)
glob = [1,2]
print f([3,4])

C'est au programmeur de s'assurer qu'il appelle "bien" f(), donc de
savoir ce que peut bien valoir glob au moment de l'appel.

-- Alain.

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 bo ucle for
i in range(10), soit on s'inquiète du type pour un tas de raisons, p ar
ex éviter un sql injection, hors dans ce cas le type ne suffira
généralement pas, il faudra surement vérifier d'autres cho ses. 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éclar ations
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.

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équenc e. Du coup on
a un peu l'avantage des deux, pas de déclaration mais une vérif ication
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.

-- Alain.

Alain Ketterlin wrote:
[snip]

Un programme bien typé statiquement est en général plus efficace parce
qu'il y a moins de choix à faire à l'exécution. Par exemple, si tu écris
a+b, à l'exécution l'interpréteur python doit aller chercher la
définition de l'opérateur + dans la classe de a (je choisis l'exemple à
dessein parce qu'en fait c'est plus compliqué que cela). Avec le typage,
il saurait d'entrée qu'il s'agit de la méthode __add__ de ma classe
Machin (après avoir vu le code qui précède).

Sauf qu'en fait non, parce qu'on est dans un langage orienté objet et que a,
déclaré comme instance de Machin, peut très bien être une instance d'une
sous-classe de Machin avec une autre implémentation de __add__. Donc il y aura
de toutes façons une recherche de la méthode à l'exécution. La seule chose qui
peut être garantie par le typage statique, c'est que la méthode existe bien.

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 ;-) 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. Il n'y a juste ni déclarations, ni inférence de type. Mais tous les
objets Python connaissent leur type et génèreront une erreur s'ils ne sont pas
utilisés correctement. Par contre, ce sera une erreur à l'exécution; ça, je
comprend que ça puisse être un problème.

Cela dit, compte tenu du fait que le typage statique ne peut en aucun cas
garantir la correction de ton code, de toutes façons, tu vas devoir faire des
tests unitaires pour les fonctionnalités que tu implémentes. Les aficionados
du typage dynamique couplé au "test driven development" - dont je suis - te
diront que dans ce cadre, la très grande majorité des problèmes de types sera
de toutes façons identifiée par les tests unitaires. Donc déclarer les types
statiquement est juste une perte de temps pour pas grand chose, puisque les
problèmes que cela te permettrait de remonter seront de toutes façons
identifiés plus tard par les tests fonctionnels. Il y a effectivement un
risque que certains passent au travers, mais d'expérience, je crois pouvoir
dire que ce risque est vraiment mineur (plusieurs centaines de milliers de
lignes de code Python à mon actif pour une application professionnelle depuis
plus de 8 ans; les problèmes qui auraient pu être identifiés par un typage
statique et qui se sont retrouvés dans une version livrée se comptent sur les
doigts d'une main...).

Mais j'avoue que je serais quand même intéressé par une mesure objective du
gain induit par un typage statique, même si au jour d'aujourd'hui, je suis à
peu près persuadé du résultat...
- Eric -

Eric Brunel <eric.brunel@nospam-pragmadev.com> writes:

Alain Ketterlin wrote:
[snip]

Un programme bien typé statiquement est en général plus e fficace parce
qu'il y a moins de choix à faire à l'exécution. Par exemp le, si tu écris
a+b, à l'exécution l'interpréteur python doit aller cherc her la
définition de l'opérateur + dans la classe de a (je choisis l' exemple à
dessein parce qu'en fait c'est plus compliqué que cela). Avec le ty page,
il saurait d'entrée qu'il s'agit de la méthode __add__ de ma c lasse
Machin (après avoir vu le code qui précède).

Sauf qu'en fait non, parce qu'on est dans un langage orienté objet et
que a, déclaré comme instance de Machin, peut très bien être une
instance d'une sous-classe de Machin avec une autre implémentation de
__add__. Donc il y aura de toutes façons une recherche de la mé thode à
l'exécution. La seule chose qui peut être garantie par le typage
statique, c'est que la méthode existe bien.

Oui, tu as raison bien sûr, sauf que dans le cas de + c'est plus
compliqué que cela (il faut d'abord tester tous les types builtin, sauf
à faire systématiquement un appel, et tester les "optimisations" du
style a=a+b, etc. -- cf. les "coercion rules" dans le manuel de
référence). Et la recherche de la méthode à l'exéc ution pourrait se
résumer à un appel indirect (mais pas en python, parce qu'on n'es t même
pas sûr qu'elle existe, il faut consulter un ou plusieurs dictionnaire à
chaque appel).

Cela dit, on peut même des fois éviter l'appel indirect, et les
compilateurs essaient de résoudre statiquement. C'est pourquoi C++ a
virtual, Java a final... Mais on est très loin de python.

-- Alain.