Salut.
Bah ma question est basique, mais je ne l'ai jamais fait: comment rendre un fichier python executable de sorte à pouvoir par exemple le testé sur un autre ordi ?

Merci bien.

Bonjour,

va voir du côté du Py2exe. Le tutoriel présent sur le site est plutôt bien fait.
Bonne journée.
Realmagma.

Sous quel OS ?

Py2exe est une solution plus ou moins acceptable sous Windows, bien que le programme soit en général un peu plus lent de cette manière (les divers scripts sont systématiquement réinterprétés, sans conservation du bytecode), ce qui peut être handicapant si ton appli fait beaucoup de choses en pur python.

Sous linux, il suffit de coller un shebang à la toute première ligne du programme :

#! /usr/bin/env python

# ou bien, pour python3 :
#! /usr/bin/env python3

et de rendre ce fichier exécutable :

chmod +x monscript.py

Et pour windows, tu n'as qu'à dire aux gens d'installer Python (de toute façon, c'est un peu ce que fait Py2exe silencieusement : il embarque dans ton code les parties de l'interpréteur dont tu as besoin).

NoHaR, pour faire ce que tu a dit, je dois utiliser la console de mon OS ou celle de Python?

Je pense que Maxibolt a raison, le mieux et le plus léger c'est d'installer python chez tes amis.

mh... C'est pas très pratique, moi je pensais plutôt à un fichier sur un disque qu'on met dans le lecteur, hop on ouvre tout ça et on clique sur l'exe...

Si tu veux un genre d'installeur à la windôbs, tu peux aller voir du coté de Inno Setup. Tu pourras ainsi soit placer la version de python qui doit être utilisée par tes scripts et bien sûr tes scripts directement dans l'installeur, soit faire en sorte que l'installeur télécharge python et l'installe si besoin en plus de tes scripts.

désolé, trompé de post.

Citation : ShikiSokuZeku

NoHaR, pour faire ce que tu a dit, je dois utiliser la console de mon OS ou celle de Python?

La commande console est pour rendre un script exécutable sous les OS type Unix.

Citation : ShikiSokuZeku

mh... C'est pas très pratique, moi je pensais plutôt à un fichier sur un disque qu'on met dans le lecteur, hop on ouvre tout ça et on clique sur l'exe...

Ça fonctionne pourtant de la même manière pour les programmes Java : sous Windows, il faut installer la JVM avant de faire tourner un programme donné.
Sous Linux, c'est beaucoup plus simple : soit la version de Python utilisée est native (donc rien à installer, juste le script à refiler), soit il "suffit" de créer un paquet binaire ayant la bonne version de Python en dépendance.

Citation

Citation : ShikiSokuZeku

mh... C'est pas très pratique, moi je pensais plutôt à un fichier sur un disque qu'on met dans le lecteur, hop on ouvre tout ça et on clique sur l'exe...

Ça fonctionne pourtant de la même manière pour les programmes Java : sous Windows, il faut installer la JVM avant de faire tourner un programme donné.
Sous Linux, c'est beaucoup plus simple : soit la version de Python utilisée est native (donc rien à installer, juste le script à refiler), soit il "suffit" de créer un paquet binaire ayant la bonne version de Python en dépendance.

Bonjour, je suis un programmeur C++, et je passais par là. Je ne connais que le strict des bases de python, mais je voulais signaler que cette solution est surement la meilleure : en C++, on est souvent obligé de fournir les .dll (ce qui correspond en quelques sortes à l'interprète python, mais très vaguement hein, juste pour faire fonctionner une partie du code (bon j'arrête, si un autre programmeur C++ passe par là, je me fais destoyer )), les ressources (images, musiques, son...) en plus de l'exécutable, et ce n'est pas réellement un problème. Pour la place un fichier zippé fais parfaitement l'affaire, et pour l'interpréteur n'est pas si lourd que celà (corigez-moi si je me trompe).
Ce qui est sûr c'est que python est fait pour être interprété, pas compilé. Un script python compilé sera peu performant par rapport à d'autres languages tel le C++ (ce n'est qu'un exemple).

Citation

Un script python compilé sera peu performant par rapport à d'autres languages tel le C++

Tu paries combien ?

Citation : Maxibolt

Citation

Un script python compilé sera peu performant par rapport à d'autres languages tel le C++

Tu paries combien ?

Je pense que le mot 'peu' n'est pas le bon mot. Un script python compilé sera toujours moins (de combien de millionièmes de secondes ?) performant; mais de très peu.
Et puis ce n'est pas ça qui va changer notre vie pour les programmes que l'on fait ...pour le moment .

Citation

Un script python compilé sera toujours moins performant

Re : tu paries combien ?

Il y aurait il des chiffres ?

Citation : realmagma

Je pense que le mot 'peu' n'est pas le bon mot. Un script python compilé sera toujours moins (de combien de millionièmes de secondes ?) performant; mais de très peu.
Et puis ce n'est pas ça qui va changer notre vie pour les programmes que l'on fait ...pour le moment .

Ca dépend du genre de programme que tu fais (avec un programme normal, j'entends bien que c'est pas une différence monstre). N'essaye pas de faire un MMO avec du python compilé... Surtout la partie serveur où 1/1 000 000 + ... + 1/1 000 000 000 ça fais une grande différence

Non mais un code Python compilé peut aller plus vite que l'équivalent C hein. Il y a plusieurs projets qui veulent faire un truc de ce genre (je pense en particulier à Pypy, il y en a d'autres). Pour l'instant, ils n'y sont pas encore arrivés, mais c'est encore en train d'évoluer beaucoup et ça va certainement se faire dans un futur plus ou moins proche. Ils ont déjà dépassé il y a un certain temps les performances d'un code Python interprété par du C - l'implémentation officielle - avec un code Python exécuté par un interpréteur écrit en... Python.

Et ne confondez pas "bas-niveau" et "rapide à l'exécution", ce n'est absolument pas directement lié (la preuve, Ocaml peut aller beaucoup plus vite que C). Il y avait un post de bluestorm qui parlait de ça ici, mais je ne le retrouve plus.

désoler de me mettre dans le sujet:

si on fait un script compiler on peut distribuer ce script et ils pourront le lancer sans installer python?sous Windows

A mon sens, en compilant python, on perd tout l'intérêt de ce langage.

Citation

A mon sens, en compilant python, on perd tout l'intérêt de ce langage.

+1

Mieux vaut demander à tes amis d'installer python, c'est mon point de vue, mais je crois que c'est celui de beaucoup aussi

Citation

Mieux vaut demander à tes amis d'installer python, c'est mon point de vue, mais je crois que c'est celui de beaucoup aussi

+1

Il pourront faire "jou-jou" avec en plus

Citation : germino

A mon sens, en compilant python, on perd tout l'intérêt de ce langage.

N'importe quoi. Ne confondez pas "compiler python" et "py2exe" (qui ne compile rien du tout).

A vrai dire, Python est un langage très dynamique.
Pour les débutants, c'est agréable car ça permet d'écrire un code plus concis, plus facile à comprendre et en fait plus simple de façon générale.

C'est aussi très intéressant pour les initiés dans le cas de Python puisqu'il utilise son typage dynamique sain (comprendre fort) pour fournir un polymorphisme dynamique axé sur le duck typing et la surcharge des méthodes (que j'ai presque envie de mettre en parallèle avec les classes de type de Haskell).
On obtient entre autre des fonctions codables très naturellement qui peuvent traiter de façon cohérente des objets différents.

Ces fonctionnalités dynamiques ont leurs avantages mais sont particulièrement lentes (normal puisqu'il y a plus de choses reléguées à l'exécution). De plus Python est un langage de haut niveau, qui fournit une grosse couche d'abstraction; des choses qui rendent la programmation plus agréable, plus intéressante mais qui pénalisent en terme de performances.
Bref, on a déjà un système de toutes façons pas taillé pour la performance, autant implémenter un interpréteur qui simplifiera l'usage, la modification des programmes, etc...
Mais en plus tout ce dynamisme est très difficile à implémenter avec un compilateur (et puis de toute façon pas intéressant du tout à faire).

C'est pour ça que la très grande majorité des langages typés dynamiquement utilisent exclusivement des interpréteurs et inversement que les langages typés statiquement utilisent des compilateurs (ce qu'ils ont aussi tout intérêt à faire).

Citation

A vrai dire, Python est un langage très dynamique.
Pour les débutants, c'est agréable car ça permet d'écrire un code plus concis, plus facile à comprendre et en fait plus simple de façon générale.

Je ne sais pas ce que tu entends par "dynamique", mais les langages fonctionnels comme Ocaml ou Haskell permettent d'écrire du code encore plus concis, et il ne correspondent pas à la définition que tu sembles donner de "dynamique".

Citation

C'est aussi très intéressant pour les initiés dans le cas de Python puisqu'il utilise son typage dynamique sain (comprendre fort) pour fournir un polymorphisme dynamique axé sur le duck typing et la surcharge des méthodes (que j'ai presque envie de mettre en parallèle avec les classes de type de Haskell).
On obtient entre autre des fonctions codables très naturellement qui peuvent traiter de façon cohérente des objets différents.

Le typage dynamique est une des choses que je regrette en Python. Pour des gros projets, ça oblige à avoir une très grande rigueur sans y être aidé par le compilateur/interpréteur, et on n'est jamais vraiment sûr de son code. En pratique, avoir des objets qui changent de type, c'est mal concevoir son programme, et on pourrait avoir un polymorphisme de second ordre à la ML (de toute façon, faire du polymorphisme sur des objets qui n'ont rien à voir, c'est casse-gueule. Sauf s'ils ont des méthodes "qui font la même chose", mais on retombe que Ocaml où le type des objets est défini par celui de leur méthodes et pas par la classe dont ils sont intanciés).

Citation

Ces fonctionnalités dynamiques ont leurs avantages mais sont particulièrement lentes (normal puisqu'il y a plus de choses reléguées à l'exécution). De plus Python est un langage de haut niveau, qui fournit une grosse couche d'abstraction; des choses qui rendent la programmation plus agréable, plus intéressante mais qui pénalisent en terme de performances.
Bref, on a déjà un système de toutes façons pas taillé pour la performance, autant implémenter un interpréteur qui simplifiera l'usage, la modification des programmes, etc...
Mais en plus tout ce dynamisme est très difficile à implémenter avec un compilateur (et puis de toute façon pas intéressant du tout à faire).

Le haut niveau ne pénalise pas en terme de performances. Par exemple, Ocaml peut être bien plus rapide que C, et est aussi très abstrait. En fait,les abstractions permettent d'avoir des garanties sur le code qui permettent d'accélérer son exécution (bluestorm expliquait ça ici, mais je ne retrouve plus le sujet).
Et avoir un compilateur Python peut au contraire être très intéressant, autant du point de vue de la réalisation que du résultat final. D'ailleurs les gens de Pypy ne se casseraient pas la tête si ça n'était pas intéressant.

Citation

C'est pour ça que la très grande majorité des langages typés dynamiquement utilisent exclusivement des interpréteurs et inversement que les langages typés statiquement utilisent des compilateurs (ce qu'ils ont aussi tout intérêt à faire).

Je ne pense pas que ça soit pour ça. L'abstraction d'un langage ne vient pas uniquement de son système de typage (les types algébriques des langages fonctionnels seraient, dans ce cas, comparables en terme de difficulté d'implémentation aux types dynamiques de Python - or on compile Haskell et Ocaml), et on peut parfaitement concevoir un langage au typage dynamique compilé, comme un langage au typage statique interprété (d'ailleurs il y a bien des projets sérieux pour compiler Python).

ce que j'aimerait juste savoir si les script compiler peuvent etre executer de partout sans installer python

j'ai envie de mettre un programme sans a avoir tout python installer pour le programme qui est tout petit

Python est dynamique au sens où les vérifications d'ordre sémantique intervienne à l'exécution. Ce système flexible est difficile à implémenter dans un compilateur car cela implique de générer un code qui se charge lui-même des vérifications faites par le compilateur lui-même dans le cadre d'un langage typé statiquement. Les données de l'exécutable sont plus complexes puisqu'elles retiennent des informations telles que leur type. En conséquence, le code produit par le compilateur d'un langage dynamiquement typé a forcément un handicap en terme de performance.

C'est pour ça qu'il n'est pas vraiment intéressant de compiler Python; d'ailleurs je connais aucun compilateur pour Python de façon stricte. J'avais expérimenté shedskin, il se contente de convertir un code Pseudo-Python (écris avec de grosses restrictions par rapport au langage) en C++.

En ce qui concerne le haut niveau, il est logique qu'il induise une baisse des performances car le code écrit est très différent du code machine (là où le C est un sur-assembleur) ce qui conduis à des structures gagnants en généricité mais moins optimisables...

OCaml a effectivement d'excellentes performances, ce qui est très impressionnant quand on voit l'abstraction fournit par le langage, son élégance et sa concision. Mais je ne vois pas d'élément logique pour que ses performances soient meilleures que celle du C (qui perdraient alors tout son intérêt). Son typage statique puissant permet de produire un code machine totalement abstrait de la notion de types (ou presque) dont la sécurité et la cohérence est vérifiée. Pas besoin de mécanisme dynamique de vérification, le code machine produit est plus léger et plus performant. C'est là l'avantage du typage statique, se débarrasser dès la compilation de la vérification des types pour produire un code sûr et performant.

Citation

Python est dynamique au sens où les vérifications d'ordre sémantique intervienne à l'exécution. Ce système flexible est difficile à implémenter dans un compilateur car cela implique de générer un code qui se charge lui-même des vérifications faites par le compilateur lui-même dans le cadre d'un langage typé statiquement. Les données de l'exécutable sont plus complexes puisqu'elles retiennent des informations telles que leur type. En conséquence, le code produit par le compilateur d'un langage dynamiquement typé a forcément un handicap en terme de performance.

Tu sais, entre écrire un compilateur dont une partie du code fait les vérifications et en écrire un qui génère ce code, c'est kif-kif à mon avis (je n'ai jamais vraiment fait de compilation, mais je pense que les deux sont tout aussi compliqués. Et puis bon, c'est pas la difficulté qui pose problème, sinon on n'aurait même pas de système d'exploitation).
Pour les performances, encore une fois, ce n'est pas forcément le cas (Pypy n'est pas encore abouti, mais il a comme projet clairement énoncé de dépasser le C, et je pense qu'il y arrivera un jour).

Citation

C'est pour ça qu'il n'est pas vraiment intéressant de compiler Python; d'ailleurs je connais aucun compilateur pour Python de façon stricte. J'avais expérimenté shedskin, il se contente de convertir un code Pseudo-Python (écris avec de grosses restrictions par rapport au langage) en C++.

ghc fait pareil.

Citation

En ce qui concerne le haut niveau, il est logique qu'il induise une baisse des performances car le code écrit est très différent du code machine (là où le C est un sur-assembleur) ce qui conduis à des structures gagnants en généricité mais moins optimisables...

OCaml a effectivement d'excellentes performances, ce qui est très impressionnant quand on voit l'abstraction fournit par le langage, son élégance et sa concision. Mais je ne vois pas d'élément logique pour que ses performances soient meilleures que celle du C (qui perdraient alors tout son intérêt). Son typage statique puissant permet de produire un code machine totalement abstrait de la notion de types (ou presque) dont la sécurité et la cohérence est vérifiée. Pas besoin de mécanisme dynamique de vérification, le code machine produit est plus léger et plus performant. C'est là l'avantage du typage statique, se débarrasser dès la compilation de la vérification des types pour produire un code sûr et performant.

Le code machine est de toute façon sans type. Et on arrive à faire plus rapide avec un langage plus abstrait parce qu'on peut garantir des choses sur les objets manipulés qu'on ne peut pas faire avec un code moins abstrait, ce qui permet d'améliorer la vitesse (encore une fois, cf. le post de bluestorm que je ne trouve pas mais qui expliquait ça très bien).


edit : http://www.siteduzero.com/forum-83-496 [...] s-niveau.html

Mmmh... Si il faut installer python sur chaque ordi qui execute un script, à quoi ça sert que Python soit dit "portable" ?

Et puis j'en déduit qu'il est par exemple impossible de coder des virus en python(Ce n'est pas mon intention), le pirate en question devrait installer Python sur chaque ordi-cible XD

Java est aussi dit portable, et tu dois avoir une JVM d'installée. C'est portable parce que t'as pas un code spécifique à chaque architecture/système d'exploitation (dans ce que l’utilises toi). Tu peux pas faire un code portable sur n'importe quelle architecture ou système d'exploitaton juste comme ça, sans utiliser quelque chose entre pour te faciliter ça, c'est pas possible.

Citation

Mmmh... Si il faut installer python sur chaque ordi qui execute un script, à quoi ça sert que Python soit dit "portable" ?

Attention, "portable" ne veut pas dire "on copie le code et ça marche", ça veut dire que le même code peut être exécuté sur n'importe quelle machine sans avoir à faire de modifications (en réalité, on doit quelquefois faire des changements, mais c'est pour l'écrasante majorité des cas du au fait qu'on fait des choses qui ne sont pas à proprement parler du Python mais dépendent du système).

A contrario, un code compilé n'est absolument pas portable, puisqu'un changement d'architecture ou de système d'exploitation le rend inutilisable (il faut alors recompiler le programme à partir du code source, lequel peut être portable).

Je ne sais pas si je suis très clair, tu as compris ?

Citation

Et puis j'en déduit qu'il est par exemple impossible de coder des virus en python(Ce n'est pas mon intention), le pirate en question devrait installer Python sur chaque ordi-cible XD

Non, parce qu'il est en réalité possible de construire un exécutable qui contienne à la fois ton code et les parties de l'interpréteur Python nécessaires à son exécution, et c'est par exemple ce que fait le programme Py2exe. Si on t'en a seulement à moitié parlé avant (NoHaR t'en a touché un mot), c'est parce que ce n'est pas forcément une très bonne pratique (en dehors du fait que ton code n'est alors pas facilement visible et modifiable). Par exemple, tu auras du coup l'interpréteur Python qui sera sur ta machine autant de fois qu'il y aura de programmes Python dessus. Pour un créateur de virus, ce n'est pas un problème (puisqu'il se moche de l'élégance du produit fini), mais pour toi, il vaut mieux éviter.
Cela dit, même si je ne m'y connais pas tellement, je pense que si je devais coder un virus un jour, je ne le ferais pas en Python mais plutôt dans un langage bas niveau qui permet plus de contrôle manuel et direct du système (à prendre avec des pincettes bien sûr, je ne suis pas sûr de ce que je dis).