Ça doit dépendre de comment tu l'éxecute ton programme non ? Et peut - être que si tu souhaites le tourner sur un OS en particulier ça pourrait être plus simple.
Si tu éxecutes tes fichiers à la volée tentes :
import sys
print sys.argv [ 0 ]
# ou alors
import os
print os.getcwd ( )
Et dis moi ce que ça donne ( si ça marche pas avec le fichier principale ça peut marcher avec ceux que tu vas créer par la suite on sait jamais ).
pour les intéressés, la deuxième fonction ne donne que le nom du dossier contenant le programme.
Non plus. Si l'on ignore que CWD signifie traditionnellement "current working directory", il suffit d'aller lire la documentation de cette fonction pour appendre qu'elle donne le nom du répertoire de travail courant, c'est-à-dire celui dans lequel l'utilisateur se trouve, ce qui n'a rien à voir avec celui qui contient le programme en cours d'exécution.
C'est légèrement dérangeant de voir ce genre de réponse : la liste sys.argv ne dépend ni de la façon dont le script est exécuté, ni de l'OS. Elle est remplie de la même façon par toutes les versions de l'interpréteur et tire son nom de l'argument argv que prend la fonction main en C. Quant à une approche par tâtonnement "essaye ça et tiens moi au courant, ah oui puis essaye ça aussi on sait jamais" pour un truc aussi trivial, c'est pas vraiment sérieux.
C'est légèrement dérangeant de voir ce genre de réponse : la liste sys.argv ne dépend ni de la façon dont le script est exécuté, ni de l'OS. Elle est remplie de la même façon par toutes les versions de l'interpréteur et tire son nom de l'argument argv que prend la fonction main en C. Quant à une approche par tâtonnement "essaye ça et tiens moi au courant, ah oui puis essaye ça aussi on sait jamais" pour un truc aussi trivial, c'est pas vraiment sérieux.
J'ai jamais prétendu être sérieux je donne juste ce qui marche pour moi ( j'ai appris le Python par moi même hein ), ensuite getcwd peut servir si il travail avec le même nom de fichier ( au cas où la première n'aurait pas marché ). Je pensais que çà serait différent si on l'exécute avec un batch ou à l'aide d'un interpréteur mais non, c'est juste sur certaines plateformes ( type iPad, serveurs ) que çà donne la position relative du fichier ( '\' ). Sinon merci de m'avoir appris quelque chose ! J'ai dormi moins bête hier. Cependant si tu pouvais prendre un tout petit peu plus de temps pour nous expliquer la solution idéal çà aurait été encore mieux ( ).
PS : Merci pour __file__ fred1599, par contre il génère un bug sur iPad ( ^^' ).
Euh, depuis l'application Python for iOS, elle doit sûrement pas le prendre en compte. De toutes manières c'est pas grave j'en ai pas besoin ( du moins maintenant ). Et en passant par les deux autres méthodes que j'ai donné plus haut on a juste ( '/' ). Soit c'est bloqué ( ce qui est possible pour protéger l'iPad ) ou alors ils ont oublié de le mettre dans l'interpréteur ( ce qui l'est moins ).
17:10 arnaud@umad(~)% cat > /home/arnaud/prg/cwd.py
import os
print(os.getcwd())
17:11 arnaud@umad(~)% cd /var/log
17:12 arnaud@umad(log)% python3 /home/arnaud/prg/cwd.py
/var/log
Le répertoire du script est ici /home/arnaud/prg alors que j'exécute mon script en me trouvant dans le dossier /var/log : il affiche /var/log qui est le répertoire courant.
Ah oui en effet, j'avais jamais fait attention à cela, mais dans un sens, c'est logique, __file__ est un indicateur sur le fichier exécuté dans un module.
Ça ne me choque pas, faut juste faire attention à ce qu'on fait...
pour les intéressés, la deuxième fonction ne donne que le nom du dossier contenant le programme.
Non plus. Si l'on ignore que CWD signifie traditionnellement "current working directory", il suffit d'aller lire la documentation de cette fonction pour appendre qu'elle donne le nom du répertoire de travail courant, c'est-à-dire celui dans lequel l'utilisateur se trouve, ce qui n'a rien à voir avec celui qui contient le programme en cours d'exécution.
Hum... J'ai ecrit un peu trop vite. Dans mon cas, j'ai constaté que cette fonction renvoyé le dossier du programme. Je m'excuse de cette tentative de désinformation involontaire. Merci beaucoup pour ses précisions.
nohar a écrit:
C'est légèrement dérangeant de voir ce genre de réponse : la liste sys.argv ne dépend ni de la façon dont le script est exécuté, ni de l'OS. Elle est remplie de la même façon par toutes les versions de l'interpréteur et tire son nom de l'argument argv que prend la fonction main en C. Quant à une approche par tâtonnement "essaye ça et tiens moi au courant, ah oui puis essaye ça aussi on sait jamais" pour un truc aussi trivial, c'est pas vraiment sérieux.
- Edité par nohar il y a environ 16 heures
Il a tenté de m'aidé et cela ma effectivement aidé. Que demander de plus ? Pour l'approche a tâtons, avoir la sympathie de répondre est déjà énorme. Demandé de se tenir au courant l'est encore plus.
En tout cas Nohar, je te remercie pour tes réponses argumentés.
C'est légèrement dérangeant de voir ce genre de réponse : la liste sys.argv ne dépend ni de la façon dont le script est exécuté, ni de l'OS. Elle est remplie de la même façon par toutes les versions de l'interpréteur et tire son nom de l'argument argv que prend la fonction main en C. Quant à une approche par tâtonnement "essaye ça et tiens moi au courant, ah oui puis essaye ça aussi on sait jamais" pour un truc aussi trivial, c'est pas vraiment sérieux.
- Edité par nohar il y a environ 16 heures
Il a tenté de m'aidé et cela ma effectivement aidé. Que demander de plus ? Pour l'approche a tâtons, avoir la sympathie de répondre est déjà énorme. Demandé de se tenir au courant l'est encore plus.
En tout cas Nohar, je te remercie pour tes réponses argumentés.
Il ne faut pas se méprendre sur ce que j'ai dit : aider et faire preuve de bonne volonté, c'est bien. Mais quand on a un doute, quel que soit le langage et le niveau, il est très important de se documenter pour être sûr de ce qu'on dit.
Lire la doc, c'est LE réflexe à avoir quand on cherche une information. En l'occurrence, il n'y avait pas besoin de tâtonner ici puisqu'il avait déjà l'intuition de la réponse : la bonne démarche dans ce cas est d'aller consulter la doc du module sys pour s' assurer que c'est portable, et faire quelques tests avant de poster pour donner une info précise : on perd 5 minutes grand max dans le processus mais on gagne la garantie d'une réponse propre, nette et précise.
Mieux encore : parfois on apprend aussi des trucs au passage. Personnellement c'est ce que je fais 99% du temps avant de répondre, à moins d'avoir une contrainte (genre smartphone dans le RER) qui m'en empêche, auquel cas soit je suis certain de ce que je dis, soit je garde ma réponse pour plus tard.
Merci, je ferais de même alors désormais. C'est vrai que je me base surtout de l'aspect pratique avant de répondre ( en général ), même si il m'arrive souvent de revoir la doc ( quand je me souviens plus exactement d'une fonction ).
Bouture.
Fonction qui retourne le nom du programme exécuté
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Clic ici petit curieux
Clic ici petit curieux
Clic ici petit curieux