dans le livre de swinnen l exercice suivant est propos=E9 :
5=2E9. =C9crivez un script qui recopie une cha=EEne (dans une nouvelle
variable) en l'inversant.
Ainsi par exemple, =AB zorglub =BB deviendra =AB bulgroz =BB.
La solution donn=E9e par l'auteur :
#! /usr/bin/env python
# -*- coding: Latin-1 -*-
# Inversion d'une cha=EEne de caract=E8res
# Cha=EEne fournie au d=E9part :
ch =3D raw_input ('entrer un mot: ' )
lc =3D len(ch) # nombre de caract=E8res total
i =3D lc - 1 # le traitement commencera =E0 partir du dernier
caract=E8re
nch =3D "" # nouvelle cha=EEne =E0 construire (vide au d =E9part)
while i >=3D 0:
nch =3D nch + ch[i]
i =3D i - 1
# Affichage :
print nch
ca marche mais je ne comprend pas pourquoi la variable "i" est
encapsul=E9 la valeur "lc - 1" et non pourquoi simplement la valeur "lc
" , j'avais fait un script similaire avant de regarder la solution
mais je n'avais pas diminuer la valeur lc de 1 . Il est =E9crit que
c'est pour commencer par le dernier caract=E8re , mais si l'on enl=E8ve
1 , ne commence t-on pas avec l'avant dernier caract=E8re ?
output erreur sans la valeur lc - 1 :
me@robby:~/python.swinnen/solutions$ python exercice_5_09.py
entrer un mot: hello
Traceback (most recent call last):
File "exercice_5_09.py", line 12, in ?
nch =3D nch + ch[i]
IndexError: string index out of range
quelqu'un peut m'expliquer ? j'ai d=E9j=E0 chercher le nom de l erreur
mais elle pas trop compr=E9hensible a ce niveau ..
Et sur d'autres machines sur lesquelles il y a plus de ressources, c'est du temps réel dur qu'il me faut. Hormis le C, point de salut.
Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas à l'exercice ?
Je ne connais pas ces langages. Comme il a été dit précédemment, le C
est le langage le plus "universel". Même si ce n'est pas toujours le plus adapté, on peut tout faire avec.
Je n'en disconviens pas - mais cela justifie-t-il ton "Hormis le C, point de salut" ?
Effectivement, il y l'assembleur qui est l'arme absolue.
Ce n'est pas vraiment à ça que je pensais !-)
(snip)
Ce que je veux dire, c'est que on trouve toujours (ou presque) un compilateur C pour un micro donné. Ce qui n'est pas le cas les autres langages.
Ok sur ce point.
Et le C est tellement bas niveau (on pourrait presque dire que c'est une surcouche de l'assembleur)
En ce qui me concerne, tu peux virer le conditionnel !-)
que l'on peut générer du code pour tous les besoins. J'ai un système qui tourne avec 8Ko de ROM et 256 octets de RAM. A part l'assembleur et le C, je ne connais pas de langage adapté.
Et ce n'est pas moi qui saurait te dire si ADA, OCaml ou autres peuvent rentrer là dedans.
Et surtout, je ne connais pas d'autre langage qui possède un compilateur conçu pour mon micro. Attention, je n'ai pas dit que le C est le langage idéal ou le plus universel
Ah, si, ça tu l'a dit - regarde un peu plus haut !-)
ou quoi que ce soit d'autre. Je dis qu'on trouve toujours un compilateur C à se mettre sous la main. Et dans certains cas particuliers, genre temps réel dur, en C tout est sous contrôle.
Si tu bypasse l'OS (ce qui implique qu'il y en ait un)...
Avec d'autres langages (y compris C++), on ne maitrise pas tout.
Là, ça sort de ma (maigre) compétence.
Nicolas
(snip)
Et sur d'autres machines sur lesquelles il y a plus de ressources,
c'est du temps réel dur qu'il me faut. Hormis le C, point de salut.
Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent
pas à l'exercice ?
Je ne connais pas ces langages. Comme il a été dit précédemment, le C
est le langage le plus "universel". Même si ce n'est pas toujours le
plus adapté, on peut tout faire avec.
Je n'en disconviens pas - mais cela justifie-t-il ton "Hormis le C,
point de salut" ?
Effectivement, il y l'assembleur qui est l'arme absolue.
Ce n'est pas vraiment à ça que je pensais !-)
(snip)
Ce que je veux dire, c'est que on trouve toujours (ou presque) un
compilateur C pour un micro donné. Ce qui n'est pas le cas les autres
langages.
Ok sur ce point.
Et le C est tellement bas niveau (on pourrait presque dire que
c'est une surcouche de l'assembleur)
En ce qui me concerne, tu peux virer le conditionnel !-)
que l'on peut générer du code pour
tous les besoins. J'ai un système qui tourne avec 8Ko de ROM et 256
octets de RAM. A part l'assembleur et le C, je ne connais pas de langage
adapté.
Et ce n'est pas moi qui saurait te dire si ADA, OCaml ou autres peuvent
rentrer là dedans.
Et surtout, je ne connais pas d'autre langage qui possède un
compilateur conçu pour mon micro.
Attention, je n'ai pas dit que le C est le langage idéal ou le plus
universel
Ah, si, ça tu l'a dit - regarde un peu plus haut !-)
ou quoi que ce soit d'autre. Je dis qu'on trouve toujours un
compilateur C à se mettre sous la main.
Et dans certains cas particuliers, genre temps réel dur, en C tout est
sous contrôle.
Si tu bypasse l'OS (ce qui implique qu'il y en ait un)...
Avec d'autres langages (y compris C++), on ne maitrise
pas tout.
Et sur d'autres machines sur lesquelles il y a plus de ressources, c'est du temps réel dur qu'il me faut. Hormis le C, point de salut.
Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas à l'exercice ?
Je ne connais pas ces langages. Comme il a été dit précédemment, le C
est le langage le plus "universel". Même si ce n'est pas toujours le plus adapté, on peut tout faire avec.
Je n'en disconviens pas - mais cela justifie-t-il ton "Hormis le C, point de salut" ?
Effectivement, il y l'assembleur qui est l'arme absolue.
Ce n'est pas vraiment à ça que je pensais !-)
(snip)
Ce que je veux dire, c'est que on trouve toujours (ou presque) un compilateur C pour un micro donné. Ce qui n'est pas le cas les autres langages.
Ok sur ce point.
Et le C est tellement bas niveau (on pourrait presque dire que c'est une surcouche de l'assembleur)
En ce qui me concerne, tu peux virer le conditionnel !-)
que l'on peut générer du code pour tous les besoins. J'ai un système qui tourne avec 8Ko de ROM et 256 octets de RAM. A part l'assembleur et le C, je ne connais pas de langage adapté.
Et ce n'est pas moi qui saurait te dire si ADA, OCaml ou autres peuvent rentrer là dedans.
Et surtout, je ne connais pas d'autre langage qui possède un compilateur conçu pour mon micro. Attention, je n'ai pas dit que le C est le langage idéal ou le plus universel
Ah, si, ça tu l'a dit - regarde un peu plus haut !-)
ou quoi que ce soit d'autre. Je dis qu'on trouve toujours un compilateur C à se mettre sous la main. Et dans certains cas particuliers, genre temps réel dur, en C tout est sous contrôle.
Si tu bypasse l'OS (ce qui implique qu'il y en ait un)...
Avec d'autres langages (y compris C++), on ne maitrise pas tout.
Là, ça sort de ma (maigre) compétence.
Nicolas
jean-michel bain-cornu
On Sun, 30 Sep 2007 23:33:43 +0200, jean-michel bain-cornu wrote:
En quoi donc d'aucuns supposent-ils que le typage statique est un avantage ?
Tu dis ça parce que tu as l'habitude d'être entre gens de bonne compagnie ici... Va sur fr.comp.developpement et essaie de leur parler de Python, tu vas voir comment tu vas te faire déchirer... Je me suis désabonné du groupe rien que pour ça...
Non, non, c'est juste parce que je n'ai pas compris. En fait, je ne suis pas sûr de savoir ce que c'est que le typage statique...
En quoi donc d'aucuns supposent-ils que le typage statique est un
avantage ?
Tu dis ça parce que tu as l'habitude d'être entre gens de bonne
compagnie ici... Va sur fr.comp.developpement et essaie de leur parler
de Python, tu vas voir comment tu vas te faire déchirer... Je me suis
désabonné du groupe rien que pour ça...
Non, non, c'est juste parce que je n'ai pas compris.
En fait, je ne suis pas sûr de savoir ce que c'est que le typage statique...
On Sun, 30 Sep 2007 23:33:43 +0200, jean-michel bain-cornu wrote:
En quoi donc d'aucuns supposent-ils que le typage statique est un avantage ?
Tu dis ça parce que tu as l'habitude d'être entre gens de bonne compagnie ici... Va sur fr.comp.developpement et essaie de leur parler de Python, tu vas voir comment tu vas te faire déchirer... Je me suis désabonné du groupe rien que pour ça...
Non, non, c'est juste parce que je n'ai pas compris. En fait, je ne suis pas sûr de savoir ce que c'est que le typage statique...
Bruno Desthuilliers
On Sun, 30 Sep 2007 23:33:43 +0200, jean-michel bain-cornu wrote:
En quoi donc d'aucuns supposent-ils que le typage statique est un avantage ?
Tu dis ça parce que tu as l'habitude d'être entre gens de bonne compagnie ici... Va sur fr.comp.developpement et essaie de leur parler de Python, tu vas voir comment tu vas te faire déchirer... Je me suis désabonné du groupe rien que pour ça...
Non, non, c'est juste parce que je n'ai pas compris. En fait, je ne suis pas sûr de savoir ce que c'est que le typage statique...
Heu... c'est de l'humour, là ? Ou tu es sérieux ?
Dans le second cas, à toutes fins utiles, et en résumant/simplifiant outrageusement[1] : typage statique = vérification du typage à la compilation, en fonction soit des déclarations de types dans le code (typage statique déclaratif, cas le plus courant, cf C, C++, pascal, ADA, Java etc), soit en fonction de types génériques déduits par le compilateur de l'utilisation effective (inférence de type, plus rare, essentiellement OCaml, Haskell & co).
La raison première de la chose est de permettre au compilo d'effectuer certaines optimisations. Ce qui est un avantage indéniable du point de vue des performances.
Accessoirement, ça peut, dans certains cas, permettre de détecter à la compil certaines erreurs (potentielles) de type. Ce qui n'est pas un avantage si important AMHA compte tenu de la complexité (et donc des rsiques d'erreurs) et de la rigidité que ça peut induire.
[1] je n'ai jamais vu deux "spécialistes" des systèmes de typage tomber d'accord sur la théorie, et je ne suis en aucun cas un des ces "spécialistes".
En quoi donc d'aucuns supposent-ils que le typage statique est un
avantage ?
Tu dis ça parce que tu as l'habitude d'être entre gens de bonne
compagnie ici... Va sur fr.comp.developpement et essaie de leur parler
de Python, tu vas voir comment tu vas te faire déchirer... Je me suis
désabonné du groupe rien que pour ça...
Non, non, c'est juste parce que je n'ai pas compris.
En fait, je ne suis pas sûr de savoir ce que c'est que le typage
statique...
Heu... c'est de l'humour, là ? Ou tu es sérieux ?
Dans le second cas, à toutes fins utiles, et en résumant/simplifiant
outrageusement[1] : typage statique = vérification du typage à la
compilation, en fonction soit des déclarations de types dans le code
(typage statique déclaratif, cas le plus courant, cf C, C++, pascal,
ADA, Java etc), soit en fonction de types génériques déduits par le
compilateur de l'utilisation effective (inférence de type, plus rare,
essentiellement OCaml, Haskell & co).
La raison première de la chose est de permettre au compilo d'effectuer
certaines optimisations. Ce qui est un avantage indéniable du point de
vue des performances.
Accessoirement, ça peut, dans certains cas, permettre de détecter à la
compil certaines erreurs (potentielles) de type. Ce qui n'est pas un
avantage si important AMHA compte tenu de la complexité (et donc des
rsiques d'erreurs) et de la rigidité que ça peut induire.
[1] je n'ai jamais vu deux "spécialistes" des systèmes de typage tomber
d'accord sur la théorie, et je ne suis en aucun cas un des ces
"spécialistes".
On Sun, 30 Sep 2007 23:33:43 +0200, jean-michel bain-cornu wrote:
En quoi donc d'aucuns supposent-ils que le typage statique est un avantage ?
Tu dis ça parce que tu as l'habitude d'être entre gens de bonne compagnie ici... Va sur fr.comp.developpement et essaie de leur parler de Python, tu vas voir comment tu vas te faire déchirer... Je me suis désabonné du groupe rien que pour ça...
Non, non, c'est juste parce que je n'ai pas compris. En fait, je ne suis pas sûr de savoir ce que c'est que le typage statique...
Heu... c'est de l'humour, là ? Ou tu es sérieux ?
Dans le second cas, à toutes fins utiles, et en résumant/simplifiant outrageusement[1] : typage statique = vérification du typage à la compilation, en fonction soit des déclarations de types dans le code (typage statique déclaratif, cas le plus courant, cf C, C++, pascal, ADA, Java etc), soit en fonction de types génériques déduits par le compilateur de l'utilisation effective (inférence de type, plus rare, essentiellement OCaml, Haskell & co).
La raison première de la chose est de permettre au compilo d'effectuer certaines optimisations. Ce qui est un avantage indéniable du point de vue des performances.
Accessoirement, ça peut, dans certains cas, permettre de détecter à la compil certaines erreurs (potentielles) de type. Ce qui n'est pas un avantage si important AMHA compte tenu de la complexité (et donc des rsiques d'erreurs) et de la rigidité que ça peut induire.
[1] je n'ai jamais vu deux "spécialistes" des systèmes de typage tomber d'accord sur la théorie, et je ne suis en aucun cas un des ces "spécialistes".
jean-michel bain-cornu
En fait, je ne suis pas sûr de savoir ce que c'est que le typage statique...
Heu... c'est de l'humour, là ? Ou tu es sérieux ?
J'étais sérieux hélas.
[1] je n'ai jamais vu deux "spécialistes" des systèmes de typage tomber d'accord sur la théorie, et je ne suis en aucun cas un des ces "spécialistes". C'est aussi mon problème.
Quand on code i=1 en python, fait-on du typage statique, du typage statique implicite, ou du typage dynamique du fait qu'il n'y a pas de phase de compilation explicite ?
En fait, je ne suis pas sûr de savoir ce que c'est que le typage
statique...
Heu... c'est de l'humour, là ? Ou tu es sérieux ?
J'étais sérieux hélas.
[1] je n'ai jamais vu deux "spécialistes" des systèmes de typage tomber
d'accord sur la théorie, et je ne suis en aucun cas un des ces
"spécialistes".
C'est aussi mon problème.
Quand on code i=1 en python, fait-on du typage statique, du typage
statique implicite, ou du typage dynamique du fait qu'il n'y a pas de
phase de compilation explicite ?
En fait, je ne suis pas sûr de savoir ce que c'est que le typage statique...
Heu... c'est de l'humour, là ? Ou tu es sérieux ?
J'étais sérieux hélas.
[1] je n'ai jamais vu deux "spécialistes" des systèmes de typage tomber d'accord sur la théorie, et je ne suis en aucun cas un des ces "spécialistes". C'est aussi mon problème.
Quand on code i=1 en python, fait-on du typage statique, du typage statique implicite, ou du typage dynamique du fait qu'il n'y a pas de phase de compilation explicite ?
Sébastien Kirche
Le 1 octobre 2007 à 09:58, Eric Brunel a dit :
Tu dis ça parce que tu as l'habitude d'être entre gens de bonne compagnie ici... Va sur fr.comp.developpement et essaie de leur parler de Python, tu vas voir comment tu vas te faire déchirer... Je me suis désabonné du groupe rien que pour ça...
Je m'y suis abonné depuis peu à cause d'une discussion redirigée et pour ce que j'en ai vu, ce groupe est mort...
Pour le reste j'ai bien l'impression de ne pas avoir été compris (où alors c'était à cause du vendredi) mais bien qu'ayant d'excellents souvenirs d'Ada je suis ravi d'avoir pu introduire python (ainsi que ruby et RoR d'ailleurs) à mon boulot.
Le seul problème c'est que le chef veut bien de tout ce qu'on lui propose seulement il revient toujours nous demander si on ne peut pas « lui faire un exe » pour distribuer à ses clients.
On dirait bien que dans l'esprit de beaucoup de gens les scripts « ça ne fait pas sérieux » au contraire d'un .exe. Du coup il faut toujours ruser pour distribuer du python (ou du perl, ou du hta pour mes collègues) sous forme d'un package « exe »... Pfff :o( -- Sébastien Kirche
Le 1 octobre 2007 à 09:58, Eric Brunel a dit :
Tu dis ça parce que tu as l'habitude d'être entre gens de bonne
compagnie ici... Va sur fr.comp.developpement et essaie de leur parler
de Python, tu vas voir comment tu vas te faire déchirer... Je me suis
désabonné du groupe rien que pour ça...
Je m'y suis abonné depuis peu à cause d'une discussion redirigée et pour
ce que j'en ai vu, ce groupe est mort...
Pour le reste j'ai bien l'impression de ne pas avoir été compris (où
alors c'était à cause du vendredi) mais bien qu'ayant d'excellents
souvenirs d'Ada je suis ravi d'avoir pu introduire python (ainsi que
ruby et RoR d'ailleurs) à mon boulot.
Le seul problème c'est que le chef veut bien de tout ce qu'on lui
propose seulement il revient toujours nous demander si on ne peut pas
« lui faire un exe » pour distribuer à ses clients.
On dirait bien que dans l'esprit de beaucoup de gens les scripts « ça ne
fait pas sérieux » au contraire d'un .exe.
Du coup il faut toujours ruser pour distribuer du python (ou du perl, ou
du hta pour mes collègues) sous forme d'un package « exe »... Pfff :o(
--
Sébastien Kirche
Tu dis ça parce que tu as l'habitude d'être entre gens de bonne compagnie ici... Va sur fr.comp.developpement et essaie de leur parler de Python, tu vas voir comment tu vas te faire déchirer... Je me suis désabonné du groupe rien que pour ça...
Je m'y suis abonné depuis peu à cause d'une discussion redirigée et pour ce que j'en ai vu, ce groupe est mort...
Pour le reste j'ai bien l'impression de ne pas avoir été compris (où alors c'était à cause du vendredi) mais bien qu'ayant d'excellents souvenirs d'Ada je suis ravi d'avoir pu introduire python (ainsi que ruby et RoR d'ailleurs) à mon boulot.
Le seul problème c'est que le chef veut bien de tout ce qu'on lui propose seulement il revient toujours nous demander si on ne peut pas « lui faire un exe » pour distribuer à ses clients.
On dirait bien que dans l'esprit de beaucoup de gens les scripts « ça ne fait pas sérieux » au contraire d'un .exe. Du coup il faut toujours ruser pour distribuer du python (ou du perl, ou du hta pour mes collègues) sous forme d'un package « exe »... Pfff :o( -- Sébastien Kirche
Bruno Desthuilliers
En fait, je ne suis pas sûr de savoir ce que c'est que le typage statique...
Heu... c'est de l'humour, là ? Ou tu es sérieux ?
J'étais sérieux hélas.
[1] je n'ai jamais vu deux "spécialistes" des systèmes de typage tomber d'accord sur la théorie, et je ne suis en aucun cas un des ces "spécialistes". C'est aussi mon problème.
Quand on code i=1 en python, fait-on du typage statique, du typage statique implicite, ou du typage dynamique du fait qu'il n'y a pas de phase de compilation explicite ?
Le fait que la phase de compilation soit explicite ou non n'y change rien - d'ailleurs, tu peux explicitement compiler tes sources Python.
En ce qui concerne Python, le typage est tout à fait dynamique. Il n'y a ni déclaration de type (pour les variables/attributs et les paramètres de fonction), ni inférence. La vérification a lieu à l'exécution, et se résume le plus souvent à tenter d'utiliser l'objet, et à lancer une exception s'il n'a pas les attributs (ce qui en Python inclue les méthodes) attendus.
Pour du typage statique déclaratif, regarde du côté de Java, C, C++, C#, Ada, Pascal etc... Dans tous ces langages, tu dois déclarer le type des variables, le type des arguments et le type des fonctions (c'est à dire le type des valeurs qu'elles retournent). Ce qui, en POO, est une douleur anale majeure, puisque le même mécanisme (l'héritage) sert aussi bien pour l'implémentation que pour le typage, ce qui implique que le fait, pour un objet, d'implémenter effectivement un certain protocole ne suffit pas à le rendre substituable à un objet du type attendu. Ce qui nuit quelque peu à la généricité...
En fait, je ne suis pas sûr de savoir ce que c'est que le typage
statique...
Heu... c'est de l'humour, là ? Ou tu es sérieux ?
J'étais sérieux hélas.
[1] je n'ai jamais vu deux "spécialistes" des systèmes de typage
tomber d'accord sur la théorie, et je ne suis en aucun cas un des ces
"spécialistes".
C'est aussi mon problème.
Quand on code i=1 en python, fait-on du typage statique, du typage
statique implicite, ou du typage dynamique du fait qu'il n'y a pas de
phase de compilation explicite ?
Le fait que la phase de compilation soit explicite ou non n'y change
rien - d'ailleurs, tu peux explicitement compiler tes sources Python.
En ce qui concerne Python, le typage est tout à fait dynamique. Il n'y a
ni déclaration de type (pour les variables/attributs et les paramètres
de fonction), ni inférence. La vérification a lieu à l'exécution, et se
résume le plus souvent à tenter d'utiliser l'objet, et à lancer une
exception s'il n'a pas les attributs (ce qui en Python inclue les
méthodes) attendus.
Pour du typage statique déclaratif, regarde du côté de Java, C, C++, C#,
Ada, Pascal etc... Dans tous ces langages, tu dois déclarer le type des
variables, le type des arguments et le type des fonctions (c'est à dire
le type des valeurs qu'elles retournent). Ce qui, en POO, est une
douleur anale majeure, puisque le même mécanisme (l'héritage) sert aussi
bien pour l'implémentation que pour le typage, ce qui implique que le
fait, pour un objet, d'implémenter effectivement un certain protocole ne
suffit pas à le rendre substituable à un objet du type attendu. Ce qui
nuit quelque peu à la généricité...
En fait, je ne suis pas sûr de savoir ce que c'est que le typage statique...
Heu... c'est de l'humour, là ? Ou tu es sérieux ?
J'étais sérieux hélas.
[1] je n'ai jamais vu deux "spécialistes" des systèmes de typage tomber d'accord sur la théorie, et je ne suis en aucun cas un des ces "spécialistes". C'est aussi mon problème.
Quand on code i=1 en python, fait-on du typage statique, du typage statique implicite, ou du typage dynamique du fait qu'il n'y a pas de phase de compilation explicite ?
Le fait que la phase de compilation soit explicite ou non n'y change rien - d'ailleurs, tu peux explicitement compiler tes sources Python.
En ce qui concerne Python, le typage est tout à fait dynamique. Il n'y a ni déclaration de type (pour les variables/attributs et les paramètres de fonction), ni inférence. La vérification a lieu à l'exécution, et se résume le plus souvent à tenter d'utiliser l'objet, et à lancer une exception s'il n'a pas les attributs (ce qui en Python inclue les méthodes) attendus.
Pour du typage statique déclaratif, regarde du côté de Java, C, C++, C#, Ada, Pascal etc... Dans tous ces langages, tu dois déclarer le type des variables, le type des arguments et le type des fonctions (c'est à dire le type des valeurs qu'elles retournent). Ce qui, en POO, est une douleur anale majeure, puisque le même mécanisme (l'héritage) sert aussi bien pour l'implémentation que pour le typage, ce qui implique que le fait, pour un objet, d'implémenter effectivement un certain protocole ne suffit pas à le rendre substituable à un objet du type attendu. Ce qui nuit quelque peu à la généricité...
Sébastien Kirche
Le 1 octobre 2007 à 20:24, Bruno Desthuilliers a formulé :
Du coup il faut toujours ruser pour distribuer du python (ou du perl, ou du hta pour mes collègues) sous forme d'un package « exe »... Pfff :o(
py2exe ?
Je dois encore faire des essais, je ne sais pas si on arrive à déployer du wxpython.
<troll-du-lundi cible='mc'> Enfin bon, je dis ça mais perso je m'en fout un peu, je ne déploie que sur des machines équipées d'un système d'exploitation !-) </troll-du-lundi>
Si ça ne tenait qu'à moi... Le problème c'est que je dois tenir compte d'un facteur que je ne maîtrise pas : les clients :oP
-- Sébastien Kirche
Le 1 octobre 2007 à 20:24, Bruno Desthuilliers a formulé :
Du coup il faut toujours ruser pour distribuer du python (ou du
perl, ou du hta pour mes collègues) sous forme d'un package « exe
»... Pfff :o(
py2exe ?
Je dois encore faire des essais, je ne sais pas si on arrive à déployer
du wxpython.
<troll-du-lundi cible='mc'>
Enfin bon, je dis ça mais perso je m'en fout un peu, je ne déploie que
sur des machines équipées d'un système d'exploitation !-)
</troll-du-lundi>
Si ça ne tenait qu'à moi... Le problème c'est que je dois tenir compte
d'un facteur que je ne maîtrise pas : les clients :oP
Le 1 octobre 2007 à 20:24, Bruno Desthuilliers a formulé :
Du coup il faut toujours ruser pour distribuer du python (ou du perl, ou du hta pour mes collègues) sous forme d'un package « exe »... Pfff :o(
py2exe ?
Je dois encore faire des essais, je ne sais pas si on arrive à déployer du wxpython.
<troll-du-lundi cible='mc'> Enfin bon, je dis ça mais perso je m'en fout un peu, je ne déploie que sur des machines équipées d'un système d'exploitation !-) </troll-du-lundi>
Si ça ne tenait qu'à moi... Le problème c'est que je dois tenir compte d'un facteur que je ne maîtrise pas : les clients :oP
-- Sébastien Kirche
Sébastien Kirche
Le 2 octobre 2007 à 22:42, Amaury Forgeot d'Arc a formulé :
py2exe ?
Je dois encore faire des essais, je ne sais pas si on arrive à déployer du wxpython.
ça marche très bien: http://wiki.wxpython.org/index.cgi/SmallApp
Merci pour le lien, je regarde ça de très près ASAP. -- Sébastien Kirche
Le 2 octobre 2007 à 22:42, Amaury Forgeot d'Arc a formulé :
py2exe ?
Je dois encore faire des essais, je ne sais pas si on arrive à
déployer du wxpython.
ça marche très bien:
http://wiki.wxpython.org/index.cgi/SmallApp
Merci pour le lien, je regarde ça de très près ASAP.
--
Sébastien Kirche
