Dans un livre ("Apprendre à programmer avec Python" de Swinnen),
l'auteur explique (assez rapidement car ces questions ne sont vraiment
pas l'objet du livre) que Python serait une sorte de langage
intermédiaire entre "langage interprété"/"langage compilé". Il dit que
lorsqu'on fourni un source à Python:
1) Python commence à compiler le source en un code intermédiaire le
"bytecode", qui n'est pas un code exécutable directement, mais qui est
un code en langage machine (en binaire) et qui serait portable en plus.
2) Ensuite, c'est ce bytecode qui est interprété (par ... un
interpréteur) pour qu'il y ait exécution du programme. Comme le bytecode
est en langage machine, son interprétation est un peu plus rapide que
pour un langage interprété "classique", mais moins que pour un
exécutable binaire classique quand même.
a) Déjà, êtes vous d'accord avec tout ceci ? N'hésitez pas à me
rectifier la moindre imprécision (je trouve que c'est plus bénéfique).
b) Si tout cela est exact, alors est-il possible de récupérer le
bytecode d'un script quelconque (d'un simple hello world) ? Par exemple,
j'ai un script Python toto.py, je le "pré-compile" en toto.bytecode et
je peux lancer mon programme avec une commande du genre :
un premier lancement de programme (où il y a pré-compilation) est toujours sensiblement plus long qu'un deuxième lancement (où il n'y a pas de pré-compilation) ?
oui, c'est un peu plus long.
Pour des scripts assez longs et complexes, cette différence de temps peut-elle être assez sensible ou cela reste quelque chose d'imperceptible ? (c'est toujours par pure curiosité)
Donc effectivement, lancer le bytecode toto.pyc plutôt que le script toto.py n'a effectivement aucun intérêt, sauf pour le premier lancement. Donc, définitivement, ça n'a vraiment aucun intérêt d'une manière générale. :-)
En fait, il est donc inexact de dire que Python est un langage 100% interprété (chose que j'ignorais). Cette notion de bytecode n'était vraiment pas claire pour moi jusqu'à présent. Là, je pense que c'est clair. Je trouve ça étonnant que ce bytecode soit du binaire portable (binaire + portable me semble plutôt incompatible). J'imagine que cette procédure hybride entre la compilation et l'interprétation est une chose "relativement moderne".
Il me reste l'exemple basique fourni par Yves à comprendre. Je ne saisis pas trop les deux dernières lignes de maBibliothèque.py et je ne comprends pas trop pourquoi un .pyc est généré dans le répertoire courant et pourquoi il se nomme maBibliothèque.pyc et non pas monProgramme.pyc.
Merci encore.
François
Tu as tout compris :)
Ok, merci beaucoup.
un premier lancement de programme (où il
y a pré-compilation) est toujours sensiblement plus long qu'un deuxième
lancement (où il n'y a pas de pré-compilation) ?
oui, c'est un peu plus long.
Pour des scripts assez longs et complexes, cette différence de temps
peut-elle être assez sensible ou cela reste quelque chose
d'imperceptible ? (c'est toujours par pure curiosité)
Donc effectivement, lancer le bytecode toto.pyc plutôt que le script
toto.py n'a effectivement aucun intérêt, sauf pour le premier lancement.
Donc, définitivement, ça n'a vraiment aucun intérêt d'une manière
générale. :-)
En fait, il est donc inexact de dire que Python est un langage 100%
interprété (chose que j'ignorais). Cette notion de bytecode n'était
vraiment pas claire pour moi jusqu'à présent. Là, je pense que c'est
clair. Je trouve ça étonnant que ce bytecode soit du binaire portable
(binaire + portable me semble plutôt incompatible). J'imagine que cette
procédure hybride entre la compilation et l'interprétation est une chose
"relativement moderne".
Il me reste l'exemple basique fourni par Yves à comprendre.
Je ne saisis pas trop les deux dernières lignes de maBibliothèque.py et
je ne comprends pas trop pourquoi un .pyc est généré dans le répertoire
courant et pourquoi il se nomme maBibliothèque.pyc et non pas
monProgramme.pyc.
un premier lancement de programme (où il y a pré-compilation) est toujours sensiblement plus long qu'un deuxième lancement (où il n'y a pas de pré-compilation) ?
oui, c'est un peu plus long.
Pour des scripts assez longs et complexes, cette différence de temps peut-elle être assez sensible ou cela reste quelque chose d'imperceptible ? (c'est toujours par pure curiosité)
Donc effectivement, lancer le bytecode toto.pyc plutôt que le script toto.py n'a effectivement aucun intérêt, sauf pour le premier lancement. Donc, définitivement, ça n'a vraiment aucun intérêt d'une manière générale. :-)
En fait, il est donc inexact de dire que Python est un langage 100% interprété (chose que j'ignorais). Cette notion de bytecode n'était vraiment pas claire pour moi jusqu'à présent. Là, je pense que c'est clair. Je trouve ça étonnant que ce bytecode soit du binaire portable (binaire + portable me semble plutôt incompatible). J'imagine que cette procédure hybride entre la compilation et l'interprétation est une chose "relativement moderne".
Il me reste l'exemple basique fourni par Yves à comprendre. Je ne saisis pas trop les deux dernières lignes de maBibliothèque.py et je ne comprends pas trop pourquoi un .pyc est généré dans le répertoire courant et pourquoi il se nomme maBibliothèque.pyc et non pas monProgramme.pyc.
Merci encore.
François
Laurent Pointal
Le Sun, 30 Mar 2008 15:01:09 +0200, Francois a écrit :
<zip>
En fait, il est donc inexact de dire que Python est un langage 100% interprété (chose que j'ignorais). Cette notion de bytecode n'était vraiment pas claire pour moi jusqu'à présent. Là, je pense que c'est clair. Je trouve ça étonnant que ce bytecode soit du binaire portable (binaire + portable me semble plutôt incompatible). J'imagine que cette procédure hybride entre la compilation et l'interprétation est une chose "relativement moderne".
Sauf erreur, Java et .Net utilisent aussi un "byte-code" qui est pris en entrée par leurs machines virtuelles respectives. Après tu peux soit l'interpréter tel quel, soit passer par une phase de compilation au moment de l'utilisation ("Just In Time" - JIT). [je crois qu'on peut aussi compiler en natif du Java]
Il me reste l'exemple basique fourni par Yves à comprendre. Je ne saisis pas trop les deux dernières lignes de maBibliothèque.py et je ne comprends pas trop pourquoi un .pyc est généré dans le répertoire courant et pourquoi il se nomme maBibliothèque.pyc et non pas monProgramme.pyc.
Ton monProgramme doit importer maBibliotheque... le module principal n'est pas byte-compilé sur disque.
A+
-- Laurent POINTAL -
Le Sun, 30 Mar 2008 15:01:09 +0200, Francois a écrit :
<zip>
En fait, il est donc inexact de dire que Python est un langage 100%
interprété (chose que j'ignorais). Cette notion de bytecode n'était
vraiment pas claire pour moi jusqu'à présent. Là, je pense que c'est
clair. Je trouve ça étonnant que ce bytecode soit du binaire portable
(binaire + portable me semble plutôt incompatible). J'imagine que cette
procédure hybride entre la compilation et l'interprétation est une chose
"relativement moderne".
Sauf erreur, Java et .Net utilisent aussi un "byte-code" qui est pris en
entrée par leurs machines virtuelles respectives. Après tu peux soit
l'interpréter tel quel, soit passer par une phase de compilation au
moment de l'utilisation ("Just In Time" - JIT).
[je crois qu'on peut aussi compiler en natif du Java]
Il me reste l'exemple basique fourni par Yves à comprendre. Je ne saisis
pas trop les deux dernières lignes de maBibliothèque.py et je ne
comprends pas trop pourquoi un .pyc est généré dans le répertoire
courant et pourquoi il se nomme maBibliothèque.pyc et non pas
monProgramme.pyc.
Ton monProgramme doit importer maBibliotheque... le module principal
n'est pas byte-compilé sur disque.
Le Sun, 30 Mar 2008 15:01:09 +0200, Francois a écrit :
<zip>
En fait, il est donc inexact de dire que Python est un langage 100% interprété (chose que j'ignorais). Cette notion de bytecode n'était vraiment pas claire pour moi jusqu'à présent. Là, je pense que c'est clair. Je trouve ça étonnant que ce bytecode soit du binaire portable (binaire + portable me semble plutôt incompatible). J'imagine que cette procédure hybride entre la compilation et l'interprétation est une chose "relativement moderne".
Sauf erreur, Java et .Net utilisent aussi un "byte-code" qui est pris en entrée par leurs machines virtuelles respectives. Après tu peux soit l'interpréter tel quel, soit passer par une phase de compilation au moment de l'utilisation ("Just In Time" - JIT). [je crois qu'on peut aussi compiler en natif du Java]
Il me reste l'exemple basique fourni par Yves à comprendre. Je ne saisis pas trop les deux dernières lignes de maBibliothèque.py et je ne comprends pas trop pourquoi un .pyc est généré dans le répertoire courant et pourquoi il se nomme maBibliothèque.pyc et non pas monProgramme.pyc.
Ton monProgramme doit importer maBibliotheque... le module principal n'est pas byte-compilé sur disque.
A+
-- Laurent POINTAL -
yves
Le Sat, 29 Mar 2008 23:36:29 +0100, Francois a écrit:
Bonjour
Explication traduite de cette page: http://www.freenetpages.co.uk/hp/alan.gauld/tutfiles.htm
if __name__ == "__main__": f()
"Cet étrange morceau de code permet d'utiliser n'importe quel fichier python soit en l'important, soit comme un programme en l'exécutant.
Quelle est la différence ?: Quand le programme est importé, la variable interne __name__ prend le nom du module, et quand le fichier est exécuté, __name__ est fixée à "__main__".
Rusé, n'est-il pas ?"
b) Pourquoi diable le fichier maBibliotheque.pyc est-il créé lors de l'exécution de monProgramme.py ? Ça m'aurait moins troublé que ce soit un fichier monProgramme.pyc qui soit créé, même si sa création reste un peu mystérieuse pour moi (peut-être que la réponse est dans le a) ?).
C'est du fait de la ligne "import maBibliotheque" que maBibliotheque.pyc est créé.
Démonstration avec l'interpréteur Python: ~/asup $ ls maBibliotheque.py monProgramme.py
Python 2.5.1 (r251:54863, Mar 7 2008, 04:10:12) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import maBibliotheque
~/asup $ ls maBibliotheque.py maBibliotheque.pyc monProgramme.py
import monProgramme voici la sortie de la fonction f:
hello world
~/asup $ ls maBibliotheque.py maBibliotheque.pyc monProgramme.py monProgramme.pyc
Le tutoriel d'Alan Gauld est en anglais, mais vraiment excellent: http://www.freenetpages.co.uk/hp/alan.gauld/index.htm
Encore mieux pour un débutant, l'ancienne version de son tutoriel: http://www.freenetpages.co.uk/hp/alan.gauld/oldtutor/index.htm
Cordialement -- Yves
Le Sat, 29 Mar 2008 23:36:29 +0100, Francois a écrit:
Bonjour
Explication traduite de cette page:
http://www.freenetpages.co.uk/hp/alan.gauld/tutfiles.htm
if __name__ == "__main__":
f()
"Cet étrange morceau de code permet d'utiliser n'importe quel fichier
python soit en l'important, soit comme un programme en l'exécutant.
Quelle est la différence ?:
Quand le programme est importé, la variable interne __name__ prend le
nom du module, et quand le fichier est exécuté, __name__ est fixée à
"__main__".
Rusé, n'est-il pas ?"
b) Pourquoi diable le fichier maBibliotheque.pyc est-il créé lors de
l'exécution de monProgramme.py ? Ça m'aurait moins troublé que ce soit
un fichier monProgramme.pyc qui soit créé, même si sa création reste un
peu mystérieuse pour moi (peut-être que la réponse est dans le a) ?).
C'est du fait de la ligne "import maBibliotheque" que maBibliotheque.pyc
est créé.
Démonstration avec l'interpréteur Python:
~/asup $ ls
maBibliotheque.py monProgramme.py
Python 2.5.1 (r251:54863, Mar 7 2008, 04:10:12)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import maBibliotheque
~/asup $ ls
maBibliotheque.py maBibliotheque.pyc monProgramme.py
import monProgramme
voici la sortie de la fonction f:
hello world
~/asup $ ls
maBibliotheque.py maBibliotheque.pyc monProgramme.py monProgramme.pyc
Le tutoriel d'Alan Gauld est en anglais, mais vraiment excellent:
http://www.freenetpages.co.uk/hp/alan.gauld/index.htm
Encore mieux pour un débutant, l'ancienne version de son tutoriel:
http://www.freenetpages.co.uk/hp/alan.gauld/oldtutor/index.htm
Le Sat, 29 Mar 2008 23:36:29 +0100, Francois a écrit:
Bonjour
Explication traduite de cette page: http://www.freenetpages.co.uk/hp/alan.gauld/tutfiles.htm
if __name__ == "__main__": f()
"Cet étrange morceau de code permet d'utiliser n'importe quel fichier python soit en l'important, soit comme un programme en l'exécutant.
Quelle est la différence ?: Quand le programme est importé, la variable interne __name__ prend le nom du module, et quand le fichier est exécuté, __name__ est fixée à "__main__".
Rusé, n'est-il pas ?"
b) Pourquoi diable le fichier maBibliotheque.pyc est-il créé lors de l'exécution de monProgramme.py ? Ça m'aurait moins troublé que ce soit un fichier monProgramme.pyc qui soit créé, même si sa création reste un peu mystérieuse pour moi (peut-être que la réponse est dans le a) ?).
C'est du fait de la ligne "import maBibliotheque" que maBibliotheque.pyc est créé.
Démonstration avec l'interpréteur Python: ~/asup $ ls maBibliotheque.py monProgramme.py
Python 2.5.1 (r251:54863, Mar 7 2008, 04:10:12) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import maBibliotheque
~/asup $ ls maBibliotheque.py maBibliotheque.pyc monProgramme.py
import monProgramme voici la sortie de la fonction f:
hello world
~/asup $ ls maBibliotheque.py maBibliotheque.pyc monProgramme.py monProgramme.pyc
Le tutoriel d'Alan Gauld est en anglais, mais vraiment excellent: http://www.freenetpages.co.uk/hp/alan.gauld/index.htm
Encore mieux pour un débutant, l'ancienne version de son tutoriel: http://www.freenetpages.co.uk/hp/alan.gauld/oldtutor/index.htm
Cordialement -- Yves
yves
Le Sun, 30 Mar 2008 14:10:35 +0000, yves a écrit:
Encore mieux pour un débutant, l'ancienne version de son tutoriel: http://www.freenetpages.co.uk/hp/alan.gauld/oldtutor/index.htm
Se limiter à ce qui est consacré à Python.
-- Yves
Le Sun, 30 Mar 2008 14:10:35 +0000, yves a écrit:
Encore mieux pour un débutant, l'ancienne version de son tutoriel:
http://www.freenetpages.co.uk/hp/alan.gauld/oldtutor/index.htm
Encore mieux pour un débutant, l'ancienne version de son tutoriel: http://www.freenetpages.co.uk/hp/alan.gauld/oldtutor/index.htm
Se limiter à ce qui est consacré à Python.
-- Yves
Thierry B.
--{ Francois a plopé ceci: }--
surpris, car je pensais que, un peu comme avec le langage C, les sources de la bibliothèque standard n'étaient sur mon ordinateur.
Ceci dit, il faut être un peu maso pour vouloir se plonger dans les arcanes de la diabolique glibc...
Autre question bête : où diable se trouve le byte-code d'un script ? Sur mon bureau, j'ai un script monp.py qui est un simple "Hello world". Je le lance etc. Impossible de mettre la main sur le monp.pyc. Où se trouve ce fichier exactement ? Je n'ai pas de dossier caché .pyc créé sur mon bureau par exemple.
En fait, la génération du bytecode ne se fait que lors de l'importation d'un module, et pour _ce_ module. Jamais lors de l'exécution directe d'un programmme, pour le source de ce programme. Mais si ce programme importe un module, ce module sera bytecompilé à ce moment...
Accessoirement, où trouver une description de la machine virtuelle de Python, est-elle vraiment différente de Parrot, la convergence va-t-elle avoir lieu un jour, et est-il possible d'écrire en "assembleur" du code pour cette machine ?
tTh.
-- L'avis de décès de regroupement du groupe avec un groupe père pourrait ainsi être publié post-mortem, évitant ainsi les votes désolants et surtout les résurrections artificielles. --{ fufe et le Vaudou }--
--{ Francois a plopé ceci: }--
surpris, car je pensais que, un peu comme avec le langage C, les sources
de la bibliothèque standard n'étaient sur mon ordinateur.
Ceci dit, il faut être un peu maso pour vouloir se plonger dans
les arcanes de la diabolique glibc...
Autre question bête : où diable se trouve le byte-code d'un script ? Sur
mon bureau, j'ai un script monp.py qui est un simple "Hello world". Je
le lance etc. Impossible de mettre la main sur le monp.pyc. Où se trouve
ce fichier exactement ? Je n'ai pas de dossier caché .pyc créé sur mon
bureau par exemple.
En fait, la génération du bytecode ne se fait que lors de
l'importation d'un module, et pour _ce_ module. Jamais lors
de l'exécution directe d'un programmme, pour le source de
ce programme. Mais si ce programme importe un module, ce
module sera bytecompilé à ce moment...
Accessoirement, où trouver une description de la machine
virtuelle de Python, est-elle vraiment différente de Parrot,
la convergence va-t-elle avoir lieu un jour, et est-il possible
d'écrire en "assembleur" du code pour cette machine ?
tTh.
--
L'avis de décès de regroupement du groupe avec un groupe père pourrait
ainsi être publié post-mortem, évitant ainsi les votes désolants et
surtout les résurrections artificielles.
--{ fufe et le Vaudou }--
surpris, car je pensais que, un peu comme avec le langage C, les sources de la bibliothèque standard n'étaient sur mon ordinateur.
Ceci dit, il faut être un peu maso pour vouloir se plonger dans les arcanes de la diabolique glibc...
Autre question bête : où diable se trouve le byte-code d'un script ? Sur mon bureau, j'ai un script monp.py qui est un simple "Hello world". Je le lance etc. Impossible de mettre la main sur le monp.pyc. Où se trouve ce fichier exactement ? Je n'ai pas de dossier caché .pyc créé sur mon bureau par exemple.
En fait, la génération du bytecode ne se fait que lors de l'importation d'un module, et pour _ce_ module. Jamais lors de l'exécution directe d'un programmme, pour le source de ce programme. Mais si ce programme importe un module, ce module sera bytecompilé à ce moment...
Accessoirement, où trouver une description de la machine virtuelle de Python, est-elle vraiment différente de Parrot, la convergence va-t-elle avoir lieu un jour, et est-il possible d'écrire en "assembleur" du code pour cette machine ?
tTh.
-- L'avis de décès de regroupement du groupe avec un groupe père pourrait ainsi être publié post-mortem, évitant ainsi les votes désolants et surtout les résurrections artificielles. --{ fufe et le Vaudou }--
Thierry B.
--{ Francois a plopé ceci: }--
Je trouve ça étonnant que ce bytecode soit du binaire portable (binaire + portable me semble plutôt incompatible). J'imagine que cette procédure hybride entre la compilation et l'interprétation est une chose "relativement moderne".
- Ce n'est pas du binaire au sens "code machine pour le vrai processeur", mais plutôt "code machine pour un processeur virtuel".
- Tout dépend de ton age :) pour le "relativement moderne". Si je me souviens bien, il y avait déja quelques interpréteurs Basic qui procédaient d'une manière équivalente dans les années 80. Je pense au GFA Basic de l'Atari ST, entre autres...
-- Avec les trucs (assembleurs, compilateurs, interpréteur) j'ai eu parfois l'impression de vouloir manipuler des billes avec des gants de boxe. Mais on se fait vite au confort! --{ fr.comp.ordinosaures }--
--{ Francois a plopé ceci: }--
Je trouve ça étonnant que ce bytecode soit du binaire portable
(binaire + portable me semble plutôt incompatible). J'imagine que cette
procédure hybride entre la compilation et l'interprétation est une chose
"relativement moderne".
- Ce n'est pas du binaire au sens "code machine pour le vrai processeur",
mais plutôt "code machine pour un processeur virtuel".
- Tout dépend de ton age :) pour le "relativement moderne". Si je me
souviens bien, il y avait déja quelques interpréteurs Basic qui
procédaient d'une manière équivalente dans les années 80. Je pense
au GFA Basic de l'Atari ST, entre autres...
--
Avec les trucs (assembleurs, compilateurs, interpréteur) j'ai eu parfois
l'impression de vouloir manipuler des billes avec des gants de boxe.
Mais on se fait vite au confort!
--{ fr.comp.ordinosaures }--
Je trouve ça étonnant que ce bytecode soit du binaire portable (binaire + portable me semble plutôt incompatible). J'imagine que cette procédure hybride entre la compilation et l'interprétation est une chose "relativement moderne".
- Ce n'est pas du binaire au sens "code machine pour le vrai processeur", mais plutôt "code machine pour un processeur virtuel".
- Tout dépend de ton age :) pour le "relativement moderne". Si je me souviens bien, il y avait déja quelques interpréteurs Basic qui procédaient d'une manière équivalente dans les années 80. Je pense au GFA Basic de l'Atari ST, entre autres...
-- Avec les trucs (assembleurs, compilateurs, interpréteur) j'ai eu parfois l'impression de vouloir manipuler des billes avec des gants de boxe. Mais on se fait vite au confort! --{ fr.comp.ordinosaures }--
Thierry B.
--{ Méta-MCI (MVP) a plopé ceci: }--
AMHA, le principal gain, c'est la vérification syntaxique, qui est fait au moment du "compile()", et n'est plus nécessaire pour "exec()"
Il doit donc être possible de faire à la volée une vérification syntaxique d'un source python en écrivant quelques lignes de code... Mmmmm, plus je découvre Python, plus je trouve ça bien :)
--
How much does a slrn weigh? 42.
42 in African or European units?
British units.
--{ Méta-MCI (MVP) a plopé ceci: }--
AMHA, le principal gain, c'est la vérification syntaxique, qui est fait
au moment du "compile()", et n'est plus nécessaire pour "exec()"
Il doit donc être possible de faire à la volée une vérification
syntaxique d'un source python en écrivant quelques lignes de code...
Mmmmm, plus je découvre Python, plus je trouve ça bien :)
AMHA, le principal gain, c'est la vérification syntaxique, qui est fait au moment du "compile()", et n'est plus nécessaire pour "exec()"
Il doit donc être possible de faire à la volée une vérification syntaxique d'un source python en écrivant quelques lignes de code... Mmmmm, plus je découvre Python, plus je trouve ça bien :)
--
How much does a slrn weigh? 42.
42 in African or European units?
British units.
yves
Le Sun, 30 Mar 2008 18:17:39 +0200, Francois a écrit:
Est-ce correct ? Je me demande si 1) et 2) ne sont pas dans l'ordre inverse : Python cherche peut-être d'abord dans le répertoire courant, puis ensuite dans /usr/lib/python2.5 ?
1) et 2) sont dans l'ordre inverse. Démonstration:
~/yves $ ls ~/yves $ python Python 2.5.1 (r251:54863, Mar 7 2008, 04:10:12) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
Autre question bête : où diable se trouve le byte-code d'un script ? Sur mon bureau, j'ai un script monp.py qui est un simple "Hello world". Je le lance etc. Impossible de mettre la main sur le monp.pyc. Où se trouve ce fichier exactement ? Je n'ai pas de dossier caché .pyc créé sur mon bureau par exemple.
D'après un nommé Danny Yoo:
Python essaye automatiquement de compiler le code d'un module sur un "import". http://www.python.org/doc/2.2.3/tutnode8.html#SECTION008120000000000000000
Les programmes "main" ne sont pas automatiquement importés, c'est pourquoi on ne trouve pas de bytecode pour eux.
-- Yves
Le Sun, 30 Mar 2008 18:17:39 +0200, Francois a écrit:
Est-ce correct ? Je me demande si 1) et 2) ne sont pas dans l'ordre
inverse : Python cherche peut-être d'abord dans le répertoire courant,
puis ensuite dans /usr/lib/python2.5 ?
1) et 2) sont dans l'ordre inverse. Démonstration:
~/yves $ ls
~/yves $ python
Python 2.5.1 (r251:54863, Mar 7 2008, 04:10:12)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Autre question bête : où diable se trouve le byte-code d'un script ? Sur
mon bureau, j'ai un script monp.py qui est un simple "Hello world". Je
le lance etc. Impossible de mettre la main sur le monp.pyc. Où se trouve
ce fichier exactement ? Je n'ai pas de dossier caché .pyc créé sur mon
bureau par exemple.
D'après un nommé Danny Yoo:
Python essaye automatiquement de compiler le code d'un module sur un
"import".
http://www.python.org/doc/2.2.3/tutnode8.html#SECTION008120000000000000000
Les programmes "main" ne sont pas automatiquement importés, c'est
pourquoi on ne trouve pas de bytecode pour eux.
Le Sun, 30 Mar 2008 18:17:39 +0200, Francois a écrit:
Est-ce correct ? Je me demande si 1) et 2) ne sont pas dans l'ordre inverse : Python cherche peut-être d'abord dans le répertoire courant, puis ensuite dans /usr/lib/python2.5 ?
1) et 2) sont dans l'ordre inverse. Démonstration:
~/yves $ ls ~/yves $ python Python 2.5.1 (r251:54863, Mar 7 2008, 04:10:12) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
Autre question bête : où diable se trouve le byte-code d'un script ? Sur mon bureau, j'ai un script monp.py qui est un simple "Hello world". Je le lance etc. Impossible de mettre la main sur le monp.pyc. Où se trouve ce fichier exactement ? Je n'ai pas de dossier caché .pyc créé sur mon bureau par exemple.
D'après un nommé Danny Yoo:
Python essaye automatiquement de compiler le code d'un module sur un "import". http://www.python.org/doc/2.2.3/tutnode8.html#SECTION008120000000000000000
Les programmes "main" ne sont pas automatiquement importés, c'est pourquoi on ne trouve pas de bytecode pour eux.
En fait, la génération du bytecode ne se fait que lors de l'importation d'un module, et pour _ce_ module. Jamais lors de l'exécution directe d'un programme, pour le source de ce programme. Mais si ce programme importe un module, ce module sera bytecompilé à ce moment...
1) Ah ! C'est un élément nouveau ça. Un script toto.py n'est jamais "byte-compilé" lors de son exécution. Mais alors, je suis un peu perdu, car je croyais que pour exécuter un script, Python le transformait toujours en byte-code pour que le processeur virtuel Python l'exécute. Si mon toto.py n'est pas "byte-compilé", comment peut-il être exécuté ?
2) Une autre question me taraude. J'en reviens à la question du "est-ce qu'on y gagne à byte-compiler un script ?". Dans la discussion, on en était arrivé à dire que "non, on y gagne quasiment rien" (à part une vérification dérisoire de date). Mais, à la lumière de cet élément, j'aurais plutôt tendance à dire "oui on y gagne" maintenant. En effet, si j'ai un script toto.py. Je m'arrange pour le transformer en toto.pyc (en transformant mon toto.py en module et en mettant if __name__ == "__main__": comme l'a montré Yves). Dans ce cas, l'exécution de toto.pyc sera plus rapide que toto.py (qui lui n'est même pas byte-compilé alors que toto.pyc l'est déjà). Est-ce que je dis des bêtises ?
François
Merci beaucoup pour ces informations.
En fait, la génération du bytecode ne se fait que lors de
l'importation d'un module, et pour _ce_ module. Jamais lors
de l'exécution directe d'un programme, pour le source de
ce programme. Mais si ce programme importe un module, ce
module sera bytecompilé à ce moment...
1) Ah ! C'est un élément nouveau ça. Un script toto.py n'est jamais
"byte-compilé" lors de son exécution. Mais alors, je suis un peu perdu,
car je croyais que pour exécuter un script, Python le transformait
toujours en byte-code pour que le processeur virtuel Python l'exécute.
Si mon toto.py n'est pas "byte-compilé", comment peut-il être exécuté ?
2) Une autre question me taraude. J'en reviens à la question du "est-ce
qu'on y gagne à byte-compiler un script ?". Dans la discussion, on en
était arrivé à dire que "non, on y gagne quasiment rien" (à part une
vérification dérisoire de date).
Mais, à la lumière de cet élément, j'aurais plutôt tendance à dire "oui
on y gagne" maintenant. En effet, si j'ai un script toto.py. Je
m'arrange pour le transformer en toto.pyc (en transformant mon toto.py
en module et en mettant if __name__ == "__main__": comme l'a montré
Yves). Dans ce cas, l'exécution de toto.pyc sera plus rapide que toto.py
(qui lui n'est même pas byte-compilé alors que toto.pyc l'est déjà).
Est-ce que je dis des bêtises ?
En fait, la génération du bytecode ne se fait que lors de l'importation d'un module, et pour _ce_ module. Jamais lors de l'exécution directe d'un programme, pour le source de ce programme. Mais si ce programme importe un module, ce module sera bytecompilé à ce moment...
1) Ah ! C'est un élément nouveau ça. Un script toto.py n'est jamais "byte-compilé" lors de son exécution. Mais alors, je suis un peu perdu, car je croyais que pour exécuter un script, Python le transformait toujours en byte-code pour que le processeur virtuel Python l'exécute. Si mon toto.py n'est pas "byte-compilé", comment peut-il être exécuté ?
2) Une autre question me taraude. J'en reviens à la question du "est-ce qu'on y gagne à byte-compiler un script ?". Dans la discussion, on en était arrivé à dire que "non, on y gagne quasiment rien" (à part une vérification dérisoire de date). Mais, à la lumière de cet élément, j'aurais plutôt tendance à dire "oui on y gagne" maintenant. En effet, si j'ai un script toto.py. Je m'arrange pour le transformer en toto.pyc (en transformant mon toto.py en module et en mettant if __name__ == "__main__": comme l'a montré Yves). Dans ce cas, l'exécution de toto.pyc sera plus rapide que toto.py (qui lui n'est même pas byte-compilé alors que toto.pyc l'est déjà). Est-ce que je dis des bêtises ?
