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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Francois
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
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.
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
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
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).
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
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
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 ?
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
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 :
Quel meilleure preuve de la non interprétation de la machine virtuelle CPython qu'une représentation textuelle des opcodes utilisés ?
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 :
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 :
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\)
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
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).
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\)
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
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)
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\)
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
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.
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\)
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
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.
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
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.
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.
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.
