Preuve de non interprétation ?

Le
Méta-MCI \(MVP\)
Bonjour !

A votre avis, le code ci-dessous est-il suffisant, pour montrer que
l'implémentation courante (sous Windows, pour moi) de Python est
compilée, et non interprétée ?

a11

def f(b=a):
print b

a"22
f() #donne: 1111



@-salutations
--
Michel Claveau
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Francois
Le #16626241
Méta-MCI (MVP) a écrit :
Bonjour !

A votre avis, le code ci-dessous est-il suffisant, pour montrer que
l'implémentation courante (sous Windows, pour moi) de Python est
compilée, et non interprétée ?

a11

def f(b=a):
print b

a"22
f() #donne: 1111



Bonjour,

À mon avis non. Pour moi, il montre seulement que la liaison du
paramètre formel b de la fonction f avec l'objet a comme valeur-objet
par défaut se fait au moment de l'instruction def uniquement et pas à
chaque appel de f (chose dont on se rend encore mieux compte quand a est
un objet modifiable et que f le modifie). ÀMHA, c'est tout ce que cela
prouve et rien d'autre.


--
François
Bruno Desthuilliers
Le #16627041
Méta-MCI (MVP) a écrit :
Bonjour !

A votre avis, le code ci-dessous est-il suffisant, pour montrer que
l'implémentation courante (sous Windows, pour moi) de Python est
compilée, et non interprétée ?

a11

def f(b=a):
print b

a"22
f() #donne: 1111





En quoi cela prouverait-il quoi que ce soit sur l'implémentation ? Et
pourquoi veux-tu "prouver" ce qui est amplement documenté, à savoir que
CPython utilise un schéma bytecode/VM (ce qui peut être décrit aussi
bien comme une compilation que comme une interprétation).

@-salutations


Eric Deveaud
Le #16629501
Méta-MCI (MVP) wrote:
Bonjour !

A votre avis, le code ci-dessous est-il suffisant, pour montrer que
l'implémentation courante (sous Windows, pour moi) de Python est
compilée, et non interprétée ?

a11

def f(b=a):
print b

a"22
f() #donne: 1111




une belle fermeture, rien d'autre.

Eric
Christophe
Le #16629491
Méta-MCI (MVP) a écrit :
Bonjour !

A votre avis, le code ci-dessous est-il suffisant, pour montrer que
l'implémentation courante (sous Windows, pour moi) de Python est
compilée, et non interprétée ?

a11

def f(b=a):
print b

a"22
f() #donne: 1111



@-salutations



Difficile de se rendre compte de ce genre de chose de l'interrieur même
du système. Il vaut largement mieux se référer à la doc ou au code
source mais si vraiment nécessaire, un passage par le module dis peut
peut-être suffire :

>>> def myfunc(alist):
... return len(alist)


>>> dis.dis(myfunc)
2 0 LOAD_GLOBAL 0 (len)
3 LOAD_FAST 0 (alist)
6 CALL_FUNCTION 1
9 RETURN_VALUE


Quel meilleure preuve de la non interprétation de la machine virtuelle
CPython qu'une représentation textuelle des opcodes utilisés ?
Bruno Desthuilliers
Le #16629481
Christophe a écrit :
(snip)

Quel meilleure preuve de la non interprétation de la machine virtuelle
CPython qu'une représentation textuelle des opcodes utilisés ?



Pour quelle définition de "interprétation" ?-)
Méta-MCI \(MVP\)
Le #16632931
Bonsoir !

À mon avis non.



A la réflexion, pour moi aussi, c'est non.


Pour moi, il montre seulement que la liaison du paramètre formel b de
la fonction f avec l'objet a comme valeur-objet par défaut se fait au
moment de l'instruction def uniquement



Là, pas tout à fait. Car ça montre aussi que les instructions (dont le
def) sont exécutées dans l'ordre linéaire ; c'est qui semble normal,
mais va mieux en le précisant (ça aurait pu être au moment du besoin ;
"just in time", comme les itérateurs ou générateurs).

@+

MCI
Méta-MCI \(MVP\)
Le #16633481
Bonsoir !

ce qui peut être décrit aussi bien comme une compilation que comme une
interprétation



Tu as raison. la notion de compilation ou d'interprétation est très
ambiguë. En plus, elles ne sont pas complètement séparées ; car
lorsqu'un interpréteur peut très bien compiler ligne à ligne.

Finalement, je crois ne connaitre qu'un seul véritable interpréteur :
Batch. En effet, pendant qu'un batch boucle, on modifie (depuis une
autre session) une ligne de la boucle, la nouvelle ligne sera
immédiatement utilisée.


Maintenant, le pourquoi : je me suis heurté, sur un forum privé, avec un
"expert en langages", qui affirme avec continuité que Python est un
langage interprété. (au passage, il estime aussi Python faiblement
typé, avec comme argument : a3; a="ABC"; mais, là, je l'ai
bloqué, en expliquant le découplage objet/nom_d'objet)


@-salutations
--
Michel Claveau
Méta-MCI \(MVP\)
Le #16633751
Re !

quelle définition de "interprétation" ?



C'est presque caractéristique, lorsqu'on se frotte à Python : les
notions deviennent floue, s'entrechoquent, se dissolvent mutuellement.
Exemples : typage, héritage & délégation, fonctions méthodes et
propriétés, etc.

@+
--
Michel Claveau
Méta-MCI \(MVP\)
Le #16633741
Bonsoir !

Désolé, je ne vois pas où est la fermeture. Car, dans f, on n'adresse
pas d'objet du/des conteneur(s).
Si tu pouvais éclairer ma lanterne, merci d'avance.

@-salutations
--
Michel Claveau
Bruno Desthuilliers
Le #16634811
Méta-MCI (MVP) a écrit :
Bonsoir !

ce qui peut être décrit aussi bien comme une compilation que comme une
interprétation



Tu as raison. la notion de compilation ou d'interprétation est très
ambiguë. En plus, elles ne sont pas complètement séparées ; car
lorsqu'un interpréteur peut très bien compiler ligne à ligne.

Finalement, je crois ne connaitre qu'un seul véritable interpréteur :
Batch. En effet, pendant qu'un batch boucle, on modifie (depuis une
autre session) une ligne de la boucle, la nouvelle ligne sera
immédiatement utilisée.


Maintenant, le pourquoi : je me suis heurté, sur un forum privé, avec un
"expert en langages", qui affirme avec continuité que Python est un
langage interprété.



S'il qualifie également Java de la même façon, alors c'est correct pour
une valeur de "interprété" == "non compilé en code binaire natif
exécutable". S'il te soutient que Java est compilé et Python interprété,
alors c'est un crétin et tu perds ton temps. Renvoie le au code source
de Python et ça suffira.

(au passage, il estime aussi Python faiblement
typé, avec comme argument : a3; a="ABC"; mais, là, je l'ai
bloqué, en expliquant le découplage objet/nom_d'objet)



On peut - là aussi, selon la définition de ce qu'est un système de type
- considérer que Python est "faiblement" typé puisqu'au final, le seul
type qu'il connait est 'object'.

Ceci étant et dans la pratique, un expert qui confond typage dynamique
et typage faible est généralement expert en couennerie. C est un langage
faiblement typé - tu peux forcer n'importe quel type à être interprété
comme n'importe quel autre.
Publicité
Poster une réponse
Anonyme