Compilation de Python ?

Richard Delorme wrote:

Le python m'a l'air simple, mais peut on compiler un fichier source en
Python ?

Réponse simple : non. Python est interprété.

Non. Dans l'implémentation standard, les sources sont
(automatiquement) compilées en byte-code avant exécution.

Certes, mais le byte-code lui même est interprété dans l'implémentation
courante (il n'y a pas de standard labellisé ISO, AFNOR, DIN, ANSI ou
autre pour Python que je sache).
Ok. Je voulais surtout pointer que

1/ le fait d'être interprété ou compilé est une caractéristique d'une
implémentation, pas d'un langage
2/ en l'occurrence, dans l'implémentation 'standard' de Python, il y a
bel et bien compilation. Ce qui est techniquement différent d'une
implémentation strictement interprétée.

Et c'est cette ultime interprétation
qui est le facteur limitant dans les performances de l'ensemble.

Mmmm.... Là, ça dépasse mes compétences personnelles, mais pour ce que
j'ai cru comprendre de discussions sur clpy, il semble que le facteur
limitant soit plus le dynamisme du langage, qui imposerait en tout état
de cause un runtime suffisamment complexe pour que la compilation en
code natif n'apporte pas grand chose... Mais j'ai pu mal comprendre !-)

Mais bon, d'un autre côté, il existe des compilateurs code natif assez
efficaces pour Common Lisp, qui est encore plus dynamique que Python,
donc il devrait être possible de faire quelque chose pour Python également.

Bruno

Michel Claveau - abstraction méta-galactique non triviale en fuite
perpétuelle. wrote:

Bonsoir !

L'aspect dynamique ne joue pas que sur le typage ; il s'applique aussi au
code (à la structure du programme).


Comment, avec un code compilé, utiliser exec( ou execfile( ?

En incluant le compilateur dans le runtime ? Comment les compilateurs
Common Lisp traitent-ils le problème ?

Comment, avec un compilateur, traiter :

if a==2:
import titi as modul1
else:
import toto as modul1

?

Idem : en incluant le chargeur dans le runtime.

Les compilos Common Lisp arrivent à générer un code relativement
efficace pour un langage plus dynamique encore que Python...

Bruno Desthuilliers wrote:

Ok. Je voulais surtout pointer que
1/ le fait d'être interprété ou compilé est une caractéristique d'une
implémentation, pas d'un langage
2/ en l'occurrence, dans l'implémentation 'standard' de Python, il y a
bel et bien compilation. Ce qui est techniquement différent d'une
implémentation strictement interprétée.

Y a-t-il un seul langage qui soit entièrement 100% pur interprété selon
ces critères ? Même à l'époque, sur mon TI-99, le basic interprètait les
mots clef du langage pour les stocker comme un token d'un seul
caractère. Ce qui est un premier niveau de compilation...

--
Loïc

Y a-t-il un seul langage qui soit entièrement 100% pur interprété selon
ces critères ? Même à l'époque, sur mon TI-99, le basic interprètait les
mots clef du langage pour les stocker comme un token d'un seul
caractère. Ce qui est un premier niveau de compilation...

Ben non, c'est juste de l'analyse de codeet du stockage, ce n'est pas de
la compilation. La compilation, c'est prendre un ou plusieurs token et
les transformer en un ou plusieurs token.

Au sujet des langages interprétés/compilés, je me demande pourquoi on ne
parle jamais du forth.

Xavier Combelle wrote:

Y a-t-il un seul langage qui soit entièrement 100% pur interprété
selon ces critères ? Même à l'époque, sur mon TI-99, le basic
interprètait les mots clef du langage pour les stocker comme un token
d'un seul caractère. Ce qui est un premier niveau de compilation...

Ben non, c'est juste de l'analyse de codeet du stockage, ce n'est pas de
la compilation. La compilation, c'est prendre un ou plusieurs token et
les transformer en un ou plusieurs token.

Je ne vois pas trop ce que tu veux dire... Il prend bien les tokens G O
S U B du langage initial pour en faire un token 0x?? dans le langage
cible. La tokenisation est une des étapes de la compilation, mais n'est
pas AMA une activité distincte.

--
Loïc

Je ne vois pas trop ce que tu veux dire... Il prend bien les tokens G O
S U B du langage initial pour en faire un token 0x?? dans le langage
cible. La tokenisation est une des étapes de la compilation, mais n'est
pas AMA une activité distincte.

Je ne suis pas un spécialiste des compilateurs, mais il me semble que
GOSUB est un seul token. N'importe comment, il sera traiter comme une
seule entté logique. Pour moi, utiliser un seul octet pour le
représenter est une optimisation de l'interprétation, pas une compilation.
Pour moi l'interpretation c'est:

while 1:
lire_le_token()
interpreter_le_token()

La compilation c'est:

for token in fichier:
compiler_le_token()
produire_une_instruction()

while 1:
lire_instruction()
executer_instruction()

La deuxième étape est identique. D'ailleurs, techniquement,
seulement des instructions cablées sont réellement éxécutées.
Il y a même des processeurs qui interprêtent des opérations
qui sont sensées être exécutes (quel scandale!)

Fondamentalement,je dirais qu'il y a compilation à partir du moment
où il y a une phase de transformation dans le flot des éléments.
Par exemple, on peut pas dire que pour gérer du code en notation
polonaise inversée, il n'y a pas de compilation.