Discussion :

[eyquem]

Bonsoir,


Étant poussé à la faire, je relance ici dans une file en propre une interrogation que j’ai depuis longtemps mais qui s’est activée un peu plus fort à l’occasion d’une belle réponse de dividee dans le message suivant:
http://www.developpez.net/forums/d90...e/#post5134761
et dont voici la majeure partie:


POST DE DIVIDEE:

le problème [est] lié à l'utilisation de lambda. Le code contenu dans l'expression lambda n'est pas évalué immédiatement mais uniquement lorsque la fonction retournée par l'expression lambda est appelée. Donc la valeur de file à l'exécution de la lambda est sa valeur au point d'appel, pas au point de définition (idem pour a dans le code de airod).
Le code ci-dessous illustre également ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
>>> l = [1,2,3]>>> m = [lambda:e for e in l]
>>> m
[<function <lambda> at 0x00EF5830>, <function <lambda> at 0x00EF5770>, <function <lambda> at 0x00EF57B0>]
>>> m[0]()
3
>>> del e
>>> m[0]()
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "<interactive input>", line 1, in <lambda>
NameError: global name 'e' is not defined

La solution "pythonesque" est liée à une autre caractéristique de python: les valeurs par défaut des arguments d'une fonction sont évalués à la définition, pas à l'appel.

C'est d'ailleurs un autre piège de Python: si on donne un objet mutable comme valeur par défaut d'un argument, on risque des surprises:
[ ...se reporter au message pour cette partie de discussion...]

Mais pour le problème qui nous occupe, on va exploiter ce fait:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
>>> m = [lambda x=e:x for e in l]
>>> m[0]()
1
>>> m[1]()
2

Il est idiomatique en Python d'écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

m = [lambda e=e:e for e in l]

qui revient au même mais cela peut troubler si on ne l'a jamais vu.

On a certes une lambda avec un argument à présent, mais comme cet argument possède une valeur par défaut, on peut toujours l'appeler de la même façon.

FIN DU POST DE DIVIDEE

-----------------------------------------------------------

Et voilà ma question brouillone:



@ dividee

Tes deux messages et leurs explications m’ont laissé pantois.
Comme je n’aime pas trop les fonctions lambda, j’ai déjà eu du mal à comprendre la signification de l’expression [lambda:e for e in l]
Tout le reste, qui est passionant, m’a aussi demandé pas mal de phosphoration.

Mais j’avoue que je garde le sentiment de ne pas avoir tout bien bien compris.

Mon problème est que j’aime bien, ou j’ai besoin, de saisir ce qui se passe derrière les expressions, en coulisse du code textuel, au niveau de l’implémentation, savoir quels sont les objets, et les processus qui les affectent, qui sont en cause.

Or, à mon avis, ce dont tu parles a à voir avec des caractères fondamentaux de l’implémentation de Python, au niveau de la construction des objets et des processus dans lesquels sont impliqués des arguments.
Aussi cela m’intéresserait d’avoir tes éclaircissements sur un point qui n’est pas clair pour moi. Pas seulement dans ton post, d’une façon générale dans les docs. Mais comme tu en parles dans ton post, et avant de le laisser disparaître dans les profondeurs des pages >1 comme d’autres, je demande, toute honte bue:

que recouvre exactement le terme “évaluer“ ?

Le code contenu dans l'expression lambda n'est pas évalué immédiatement mais uniquement lorsque la fonction retournée par l'expression lambda est appelée.

La solution "pythonesque" est liée à une autre caractéristique de python: les valeurs par défaut des arguments d'une fonction sont évalués à la définition, pas à l'appel.


Il me semble qu’avnt de faire une exécution d’un programme, il y a une phase dans laquelle le texte du code est examiné (est-ce ce qu’on appelle analyse syntaxique ? est-ce l’interprétation ? par quoi est- ce fait, l’interpréteur ?... mystères opaques pour moi) pour établir un tas de trucs: espaces de noms, qualité de locale ou globale pour une variable... etc... je crois, je n’ai rien trouvé de précis sur ces aspects, ou je n’ai pas su trouver. Enfin bref.

Ce que je veux dire, c’est que j’imagine que c’est dans cette phase préalable que se situe ce que tu appelles “définition“ et que c’est à cette phase que se réfère le terme “immédiatement“.

Donc, dans ce que tu as écrit, je distingue deux sortes de moments, c’est à dire d’événements: les moments où quelque chose est défini, le moment où quelque chose est appelé.
Ce quelque chose est-il toujours un objet ?
Est-ce que “définition“ signifie “création d’un objet“.
Est-ce que tu es d’accord avec l’idée que je me fais d’une création d’objet: délimitation d’une zone mémoire par une sorte de cloture qui consiste en je ne sais quoi et oganisation des bits à l’intérieur de cette zône pour la rendre apte à représenter une structure logique donnée ?
Est-ce que “évaluer“ est synonyme de “définition“ et/ou “création d’objet“ ?



La question sollicite d’ailleurs tout un chacun qui aurait eu des aperçus au travers des brumes sur les processus concernés dans ce que je pense ètre ce qu’on appelle implémentation.
Merci

[eyquem]

il me semble que ce que tu appelle définition c'est la création des codes block (morceaux de code ayant une id et un binding référencé par un nom (mis dans un dico)) par la lecture du code (ce qui te donne les erreurs de syntaxe et autres au lancement par exemple).

PauseKawa »

PauseKawa, où vois tu dans la source (The Python Language Reference 4. Execution model ) que tu cites dans ce message un endroit où il est écrit qu’un block possède un id ?

Pour moi, dire que quelque chose a un id , c’est dire que c’est un objet. Cela s’oppose à la définition d’un block qui se trouve dans la page citée: « a piece of Python program text that is executed as a unit».

En outre, un objet peut ne pas avoir de nom quand il intervient dans un processus à la volée (c’est ce que je crois). Mais en général, tout objet a un nom pendant au moins un cours instant, le processus qui lie le nom et l’objet concret dans la mémoire étant appelé binding. Le binding n’est donc pas un nom mais un processus de nommage d'un objet, et un block ne peut donc pas posséder un binding.

Soyons rigoureux sur la terminologie, sinon on ne va pas s’y reconnaître.




J’ai lu des quantités de fois la page en question intitulée “Execution model“ mais j’avoue que même si j’ai l’impression d’y entendre les échos du monde des brumes, celui-ci me reste grosso modo assez impénétrable.

Un block est présenté au départ comme « a piece of Python program text that is executed as a unit». Pour que quelque chose s’exécute dans la machine, il faut bien que les informations contenues dans un block==texte ne restent pas sous forme de texte. Mais ce que je ne sais pas, c’est justement comment est traduit concrétement au niveau de l’électronique ces informations. Un block est il la matrice textuelle d’un objet ? D’un super-objet ? Ces machins qui en dérivent doivent ils être appelés des blocks compilés ??

Je préfèrerais avoir une description précise d’une doc ou d’un gourou plutôt que de me triturer la cervelle à essayer de me faire une idée des processus enfouis sur la base de vagues indices.




Ce n’est pas moi qui appelle “définition“ quelque chose. Je me demande justement ce que dividee, et les docs, désignent par “définition“. Et ce qui se passe dans les profondeurs de la machine. mais je crois que pour le comprendre , il faudrait que je connaisse le C.


Enfin bon, vastes questions.

[dividee]

A mon sens, un code block est compilé en bytecode et chargé en mémoire sous forme d'un code object. Le code object contient le bytecode lui-même (qui sera interprété) ainsi que quelques autres informations annexes (une liste des noms de variables locales, des variables libres, une référence au dictionnaire global, le nom du fichier source dont il provient, etc.). Une partie de ces informations ne sert d'ailleurs, je pense, que pour les messages d'erreur. L'interpréteur n'a pas réellement besoin de connaître les noms des variables ou du fichier, mais il faut pouvoir afficher un message d'erreur valable à l'utilisateur le cas échéant. Un code object peut en contenir d'autres, ceux des fonctions, classes et autre callable qui sont définis dans le code block en question.

Pour examiner le bytecode, on peut jouer avec le module dis, éventuellement suppléé par la fonction compile.

Mais le sujet d'origine concernait plutôt de la notion de closure, mais il est tard et j'en parlerais dans un prochain post.

[eyquem]

Merci pour cette réponse, dividee.

Elle m’a d’abord surpris parce que je n’avais pas accroché que le traitement d’un code source Python passe par un bytecode.
Je suis parti de ta référence à la notion de bytecode et je me suis aperçu que je me trompais en croyant vaguement cette notion de bytecode exclusive à Java comme il est trompeusement dit ici:

http://dictionnaire.phpmyvisites.net...ECODE-4193.htm
Définition du mot BYTECODE, Code intermédiaire avant la compilation d'un programme en Java.

Je comprends que j’aurais dû étudier le sujet tout seul et plus précisément avant de m’enflammer, car on en trouve mentions dans des explications sur Python. Mais il faut aller les chercher, je ne savais où commencer et surtout le sujet est embrouillé.







À une époque où j’ai cherché, je ne savais pas suffisamment de choses pour réellement comprendre et pour décrypter des présentation ambigues.

Je pense que ma confusion remonte à ma lecture mal assimilée du livre de Swinnen en tant que néophyte.
J’en ai gardé l’idée qu’il y avait d’un coté les langages compilés, comme C++, et de l’autre les langages interprétés:

Le programme tel que nous l’écrivons avec un éditeur sera appelé désormais code source. (..) il existe deux techniques principales pour effectuer la traduction d’un tel programme source en code binaire exécutable sur la machine: l’interprétation et la compilation.
Swinnen

Donc, là, dans cette introduction, Swinnen pose bien l’interprétation comme un processus qui part d’un code source TEXTUEL.

Certes à la fin du paragraphe, il signale que, comme Java, Python crée un bytecode intermédiaire, mais quand on lit que ce bytecode est similaire à un langage machine et qu’il est tout de même passé à un interpréteur on ne comprend plus rien, étant donné ce qui a été écrit plus haut.

D’autant moins quand on lit ensuite dans un article wikipedia que Java fait partie des langages toujours compilés:

Enfin, l'informatique n'étant pas à une terminologie approximative près, "langage de script" désigne parfois, dans un sens très vague, n'importe quel langage de programmation interprété (ce qui est un abus de langage : en toute rigueur le caractère interprété ou compilé se rapporte à une implémentation particulière, pas à un langage), par rapport aux langages toujours compilés comme C, C++, Java, etc.
http://fr.wikipedia.org/wiki/Langage_de_script

Et puis cette façon de Swinnen d’écrire:

Certains langages modernes TENTENT de combiner les deux techniques afin de retirer le meilleur de chacune

au lieu d’affirmer clairement que Python et Java font partie d’une troisième catégorie de langages et de les nommer explicitement “semi-interprétés“, ça entretient le caractère nébuleux de sa description en 6 lignes incompréhensible à un noob.






Par la suite, ayant lu partout que Python est un langage de script, vu des moqueries sur Python considéré comme lent parce que langage de script par opposition à des langages compilés comme C++, et lu dans wikipedia à l’article “langage de script“:

« Le langage de script est généralement exécuté à partir de fichiers contenant le code source du programme qui sera interprété. Historiquement ils ont été créés pour raccourcir le processus traditionnel de développement édition-compilation-édition des liens-exécution propre aux langages compilés. »
« Enfin, l'informatique n'étant pas à une terminologie approximative près, "langage de script" désigne parfois, dans un sens très vague, n'importe quel langage de programmation interprété (ce qui est un abus de langage : en toute rigueur le caractère interprété ou compilé se rapporte à une implémentation particulière, pas à un langage), par rapport aux langages toujours compilés comme C, C++, Java , etc. »
http://fr.wikipedia.org/wiki/Langage_de_script

mon malentendu s’est renforcé.




De plus,
- il n’y a pas tellement de langages semi-interprétés (Java, Pascal dans sa version UCSD, et ... Python, mais je n’ai pas vu passer, cités dans wikipedia

http://fr.wikipedia.org/wiki/Langage...9_informatique

- Java fait partie depuis des années des top5 et fait de l’ombre à tout ce qui lui ressemble (en l’occurence essentiellement Python)
- dans un grande majorité de cas, les applications Java ne sont pas des stand-alone sur une machine mais des applications liées au web dans lesquelles on reçoit le bytecode qui va être interprété sur le client ou le terminal (c’est ce que j’ai compris de tout ce que j’ai lu), il en résulte qu’on voit plus souvent évoqué le coté interprétation que compilation dans Java
- mais par dessus le marché, c’est le nom de “machine virtuelle“ qui est employé au lieu d’interpréteur pour Java.

Tout cela noie le poisson concernant les rapports entre compilation et interprétation , non seulement dans Python mais dans Java aussi; et l’inverse.







Je trouve aussi ceci intéressant

les performances des interpréteurs de bytecode sont généralement bien meilleures que celles des interpréteurs de scripts.
Pour bénéficier de ces avantages, aujourd'hui de nombreux langages interprétés sont en fait compilés en bytecode avant d'être exécutés par un interpréteur. C'est le cas par exemple de PHP (lorsqu'il est utilisé pour des applications), de Tcl et de Python. Un programme Java est habituellement transmis sous forme de bytecode à une machine hôte qui utilisera un compilateur à la volée pour traduire le bytecode en code machine avant exécution. Les implémentations actuelles de Perl et de Ruby utilisent non pas du bytecode, mais une structure en arbre qui se rapproche de la représentation intermédiaire des compilateurs.
http://fr.wikipedia.org/wiki/Bytecode

D’une part, ça confirme qu’outre les interpréteurs de script que je croyais les seuls à exister, il existe bien des interpréteurs de bytecode.
Et non seulement ça, mais c’est qu’en ce qui concerne certains langages qui n’ont pas été originellement conçus comme semi-interprétés, leurs développeurs en sont arrivés à considérer souhaitable/nécessaire de créer une version semi-interprétable de leur langage.

Je comprends la citation de PHP et Tcl dans cet extrait comme des exemples de tels langages originellement pleinement interprétés rendus semi-interprétés.
- Je me dis que ce mouvement général est la preuve que l’implémentation de Python comme langage semi-interprété dès le départ était une bonne idée.
- Je me demande en outre si un langage originellement interprété et rendu semi-interprété présente autant de qualités qu’il aurait pu en avoir s’il avait été implémenté dès le départ en tant que semi-interprété. En d’autres termes, un Tcl ou un PHP semi-compilé/semi-interprété gardent ils des stigmates ineffaçables de leur vie antérieure ? En bref, est-ce que la conception initiale de Python comme langage semi-interprété lui confère une longueur d’avance sur certains points, que d’anciens langages ne pourront jamais rattraper malgré une compilo-cosmétique ?







Jusqu’à présent je n’avais rien compris sur ce questions de compilation/interprétation. Ni dans Python ni dans Java , ni dans tous les autres langages à vrai dire. Java étant une usine à gaz, cela n’a rien d’étonnant. Et Python, ben j’avais rien capté non plus.
Mais quand je vois la discussion qui commence dans cette page
http://forum.nolife-tv.com/showthread.php?t=9610&page=2
je constate que je ne suis pas le seul à ne pas avoir eu les idées claires sur ce sujet.

Je pense que c’est pourtant un sujet fondamental. merci dividee de m’avoir répondu. je vais maintenant bosser le sujet dans mon coin, ça va aller, les brumes ont perdu de leur épaisseur et le sujet ne m’apparaît plus comme aussi impénétrable.
De plus, avec le module dis, je constate que Python met à notre disposition des radars. Je serais curieux de savoir dans quels autres langages il en est de même.





Pour des explications sur la notion de closure, je suis toujours preneur.
Encore merci

[PauseKawa]

Bonsoir eyquem,

Pour moi:

Il me semble que tu retrouve l'id partout

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
>>> def tutu():
...     print ("ok")
... 
>>> a=tutu
>>> print(a)
<function tutu at 0xb74ef6f4>
>>> b=tutu
>>> print(b)
<function tutu at 0xb74ef6f4>
>>>

Pointeur ? C'est sans doute cela ton id.

Par contre il vas falloir me dire le pourquoi et surtout le comment du : En outre, un objet peut ne pas avoir de nom quand il intervient dans un processus à la volée.
Comment fais tu ?

Pour le sujet d'origine c'est effectivement la closure (à la base lambda, et pour info qui as un nom > command=) et la visibilité des variables.

A lire aussi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Je dois aussi vous prévenir qu'il y a un piège terminologique pour les lecteurs familiers de l'orienté objet: le mot ``objet'' en Python ne veut pas forcément dire instance d'une classe.
Comme en C++ et Modula-3 et contrairement à Smalltalk, tous les types Python ne sont pas des classes: les types intégrés de base comme les entiers et les listes ne le sont pas, et même des types plus exotiques comme les fichiers ne le sont pas non plus.
Pourtant, tous les types en Python partagent un peu de sémantique commune, décrite au mieux par le mot objet.

Les objets possèdent une individualité, et des noms multiples (dans des portées multiples) peuvent être liés au même objet. Cela s'appelle aliasing dans d'autres langages. On ne le remarque pas de prime abord dans Python, et on peut l'ignorer pour le traitement des types de base non modifiables (nombres, chaînes de caractères, tuples). Néanmoins, l'aliasing a un effet (voulu!) sur la sémantique du code Python qui met en jeu des objets modifiables comme listes, dictionnaires et la plupart des types représentant des entités à l'exception du programme (fichiers, fenêtres, etc.). Ceci est mis à profit dans les programmes, puisque les alias se comportent comme des pointeurs à plusieurs points de vue. Par exemple, le passage en paramètre d'un objet n'est pas coûteux puisque seul un pointeur est transmis par l'implémentation; et si une fonction modifie un objet reçu en argument, l'appelant verra la modification -- ce qui élimine le besoin d'avoir deux mécanismes de passage d'arguments comme en Pascal.

Source

@-+

[dividee]

Comme tu l'as constaté, à l'heure actuelle ce n'est qu'une approximation de dire d'un langage qu'il est interprété ou compilé. Beaucoup de langages sont compilés vers une forme intermédiaire (bytecode ou autre), cette forme intermédiaire est alors interprétée (ou compilée en code natif à la volée, dans les cas les plus poussés).

Du côté des langages purement interprétés on trouve par exemple les shell scripts (bash, fichier batch windows, ...)

Au niveau suivant, je me rappelle de certaines versions de BASIC sur les ordinateurs 8 bits des années 80 qui n'enregistraient pas les programmes sous forme de fichier texte mais avec un codage particulier (par exemple, en remplaçant les mots clés par des codes numériques). Le seul but était d'éviter (ou réduire), à l'exécution, le coût de l'analyse syntaxique.

Ensuite viennent toute la gamme de langages (bon d'accord, il faudrait plutôt parler d'implémentation, mais bon...) qui utilisent des machines virtuelles (qu'on devrait plutôt appeler machines abstraites). Python et Java en font partie. Mais pourquoi de telles différences de performances entre les deux ? Le typage statique de Java y est pour beaucoup: grâce à l'analyse de type, on peut générer du (byte)code plus spécialisé, et sans avoir besoin de tests de type à l'exécution, vu qu'on s'est déjà assuré que les objets sur lesquels s'applique une opération sont du bon type. Je ne connais pas vraiment la JVM, mais je pense aussi qu'elle est de plus bas niveau que la machine virtuelle de Python. Les instructions de la JVM sont sans doute plus simples (dans le sens: plus basiques, plus proches du code machine) que celles de la machine virtuelle de Python.

A l'autre extrémité du spectre on trouve les langages compilés en code natifs (C, C++, ...).

Le spectre consiste en la division des tâches entre la compilation et l'exécution. Les premiers langages cités n'ont pas de phase de compilation et tout, y compris l'analyse syntaxique, doit être fait à l'exécution. Les derniers font un maximum de travail à la compilation et produisent un code natif directement.

[dividee]

Je dois aussi vous prévenir qu'il y a un piège terminologique pour les lecteurs familiers de l'orienté objet: le mot ``objet'' en Python ne veut pas forcément dire instance d'une classe.
Comme en C++ et Modula-3 et contrairement à Smalltalk, tous les types Python ne sont pas des classes: les types intégrés de base comme les entiers et les listes ne le sont pas, et même des types plus exotiques comme les fichiers ne le sont pas non plus.
Pourtant, tous les types en Python partagent un peu de sémantique commune, décrite au mieux par le mot objet.

Bizarre, ce paragraphe n'est pas présent dans la version originale du tutoriel Python, il me semble. A ma connaissance, en Python, type == classe. Du moins en ce qui concerne le programmeur. Les type intégrés comme les entiers et les listes sont bien des classes, ou du moins se comportent comme tels. On peut hériter des types intégrés, ils possèdent des méthodes, etc. Je préfère dire que les classes sont des types définis par l'utilisateur.

Il y a certainement une différence au niveau de l'implémentation entre les type prédéfinis et les classes, ne fusse que pour des raisons d'optimisations, mais tout est fait pour que cela soit invisible au programmeur. Je trouve ce paragraphe un peu trompeur, surtout dans un tutoriel.

[Zavonen]

Pour le lien entre type et objet je trouve le papier suivant plutôt bien fait:
http://www.cafepy.com/article/python....html#id402000