37 thoughts on “Les imports en Python”

• 

  Sam Post author 16/05/2013 at 09:16

  J’ai mal géré mon temps et je dois me casser attraper un train. Pas le temps de relire donc. Si une bonne âme veut passer par là, se serait super cool !

• 

  k4nar 16/05/2013 at 09:16

  s/claisr/clairs :) .

• 

  entwanne 16/05/2013 at 09:20

  Petite erreur, dans la liste des actions faites par `__import__`: le point 3. devrait commencer par «Si non»

• 

  kontre 16/05/2013 at 10:59

  Ayé, relu. Ça se sent quand tu ne relis pas ! ^^

  L’article est bon, mais on s’y perd facilement dans les noms de fichiers, genre dans les derniers paragraphes de “Le PYTHON PATH, en pratique”.

  Ce que c’est relou les imports circulaires. Ça force à grouper des choses fondamentalement différentes mais qui travaillent ensemble. Heureusement que le duck typing permet parfois de l’éviter.

• 

  Etienne 16/05/2013 at 13:41

  Limpide.

• 

  Sam Post author 17/05/2013 at 12:31

  J’ai updaté l’article puor rendre les noms de fichiers plus lisibbles, fournir une arbo de test et mettre un peu de zik pour faire passer la pillule.

  Tu vois autre chose à faire kontre ?

• 

  martin 17/05/2013 at 16:49

  Après avoir beaucoup chipoté en plaçant mes modules personnels dans le dossier site_package, ou en ajoutant le dossier contenant le module dans le PYTHONPATH avec un EXPORT dans mon fichier .bashrc ou bash_profile, je me suis finalement tourné vers les fichiers .pth à placer dans site-package (voir un article ancien de Bob Ipolito Using .pth files for Python development).

  Il y en a de plusieurs types dont le plus simple contient simplement le chemin du dossier à ajouter (messcrits.pth):

  /Users/Shared/Dropbox/messcripts

  et qui me donne accès à toutes les classes et les fonctions qui sont dans les fichiers présents (comme il est dans Dropbox, je peux m’en servir sur toutes les machines que j’utilise, Linux et Mac OS X, il suffit d’utiliser sur chacune un fichier .pth pointant vers le dossier).

  Il y a moyen d’ajouter plusieurs dossiers (un par ligne) comme dans (Django les supporte aussi, voir A Note on Python Paths ).
  /Library/test/django_src/trunk
/Library/tes/myproject_src/trunk

  D’autres compliquent un peu les choses en écrivant:
  import sys; sys.path.insert(0,'/Library/Frameworks/GDAL.framework/Versions/1.9/Python/2.7/site-packages')
  pour être surs que leur module soit en première position dans la liste du PYTHONPATH.

  Et enfin, certains utilisent cette technique pour changer l’appel du module comme le fichier Ngl.pth qui ne contient que PyNGL, ce qui permet d’utiliser soit
  import Ngl
  soit
  import PyNGL

• 

  glickind 18/05/2013 at 16:24

  On peut rappeler explicitement que faire un import exécute le code du fichier/module importé et faire un lien sur votre article:
  Pourquoi if __name__ == ‘__main__’ en Python ?

  Par ailleurs, comme tu as demandé une relecture:
  s/Mais si je me met ici/Mais si je me mets ici/
  s/quand tout à échoué/quand tout a échoué/

• 

  Etienne 19/05/2013 at 21:05

  C’est fou le nombre de fois où je me suis dit: “Y’a un truc à ce sujet sur S&M”, alors je google: “décorateurs site:sametmax.com”, par exemple.

  Pour dire, même si je google ‘”à poil les putes” site:sametmax.com’ je tombe sur des trucs vachement intéressants:

  4 résultats:
  – Quel hébergement Web pour les projets Python ?
  – Monitorez vos serveurs avec munin et notifications par email
  – Concurrence sans threads en python
  – FizzBuzz en Python

  Comme quoi on peut voir sa bite en gros plan et avoir aussi un cerveau…

• 

  Sam Post author 20/05/2013 at 07:14

  C’est une bonne tag line pour le blog ça.

• 

  Yohann 28/05/2013 at 09:43

  Je viens relire cet article depuis celui sur le nouveau snipet python 3 et je tombe sur ça:

  Ce n’est pas forcément ce que vous voulez. Python 3 corrige cela en permettant des imports relatifs, et Python 2.7 peut en bénéficier en important tout en haut du module :

  from __future__ import absolute_import

  c’est pas plustôt les import absolus justement que permet python3 ?

  Encore merci pour vos articles, continuez les mecs!

• 

  Sam Post author 28/05/2013 at 10:42

  C’est la même chose: tu as la synaxes des imports relatifs uniquement si tu as les imports absolus. Sinon les imports sont des imports absotifs :-) Ni absolus, ni relatifs, mais à l’arrache ^^

• 

  Mat 20/07/2013 at 19:51

  Salut,

  Merci pour le tutoriel :)

  Par contre à un moment, vous dîtes :

  Pour ce genre de scénario, il faut donc avoir le dossier qui les contient à côté de votre package. Ainsi, si j’avais des tests unitaires, je devrais faire un dossier tests à côté du dossier test_imports. Par exemple, transformer mon arbo en un truc comme ça :

  src
  …|_ test_imports
  …|_ tests

  Afin que je lance les tests en faisant python tests depuis src. Et dans mes fichiers de tests, je pourrai faire des from test_imports import truc.

  Cependant, j’ai créé la même arborescence (pour faire des tests unitaires), avec:

  test_import
  ………..|_ __init__py
  ………..|_ src
  ……………..|_ __init__
  ……………..|_ code.py
  ………..|_ tests
  ……………..|_ __init__py
  ……………..|_ test_code.py

  Tous les __init__.py sont vides.
  Dans test_code.py, j’ai mis “from src import code”

  Puis, en me plaçant dans le répertoire test_import dans une console, je fais:
  > python tests/test_code.py

  Et j’obtiens un joli ImportError, alors que c’est censé marcher d’après le paragraphe cité ci-dessus…
  En fait, j’ai testé en imprimant le sys.path, et il ajoute “test_import/tests” et non “test_import” comme indiqué…

  Qu’est ce que j’ai mal fait ?

  Mon but final est de pouvoir utiliser nosetests depuis n’importe où dans l’arborescence, sans avoir à faire des “sys.path.append()” de partout.

  Merci pour votre aide :) !

• 

  Sam Post author 22/07/2013 at 19:56

  Il faut toujours lancer la commande nose depuis le repertoire racine du projet, pas à l’interieur. Si tu veux lancer un test en particulier, tape le chemin vers ce fichier, relativement à la racine.

• 

  Marco 02/08/2014 at 06:58

  C’est coool s’t’article, j’étais venu un peu pour du q et puis au final je vais me mettre un peu au langage Python…

• 

  Sam Post author 02/08/2014 at 07:16

  sametmax: on vient pour les godes, on reste pour le code !

• 

  Anto 26/08/2014 at 15:05

  Hey ! Merci pour l’excellent article.

  Juste une curiosité au niveau de la variable PYTHONPATH: est-ce qu’il s’agit d’une variable d’environnement comme les autres ? Sous Ubuntu:

  $ workon myenv $ ipython   In [1]: import sys; sys.path Out[1]: ['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', # etc. ]   # Mais pourtant $ printenv | grep -i python # ne retourne rien

  $ workon myenv $ ipython In [1]: import sys; sys.path Out[1]: ['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', # etc. ] # Mais pourtant $ printenv | grep -i python # ne retourne rien

  J’aurais cru que virtualenvwrapper peuplerait la variable à la volée, mais ça n’a pas l’air d’être le cas.

• 

  Recher 06/03/2015 at 09:49

  Ce truc là :

  import .test_imports

  me fait une syntax error.

  À la place, j’ai mis ça :

  from . import test_imports

  et ça marche comme je veux.

  À relier à ce qui est dit ici :

  http://stackoverflow.com/questions/12398442/python-relative-import-causes-syntaxerror-exception

  C’est le même problème, mais avec “..” (les deux points) au lieu de “.” (le point tout seul).

• 

  Sam Post author 12/03/2015 at 16:02

  En effet, c’est une bourde. Je retire.

• 

  Inzaguiz 20/05/2015 at 17:20

  est-ce qu’on peut importer une fonction dans un autre fichier.py que le fichier “main” dans même dossier ? Comment ?

• 

  Max 23/05/2015 at 23:56

  @Inzaguiz — > http://indexerror.net/ :)

• 

  Nightingale 17/06/2015 at 13:54

  Hola hola,

  merci pour l’article! :)

  Petite question à laquelle je ne parviens pas à trouver une réponse, même avec l’aide de mon meilleur ami google =/

  Est-il possible de connaitre le nom du script faisant l’import d’un module?

  En somme j’aimerais qu’un module puisse avoir un comportement différent si c’est super_script1.py qui veut l’importer ou si c’est super_script2.py o_O

  • 

    Max 17/06/2015 at 14:00

    essais de poser ta question là >>> http://indexerror.net ;)

• 

  sakkal 26/08/2015 at 11:53

  Always i use

  sys.path.append(os.path.join(os.path.dirname(file),configFile))

  And i declare all paramete global

• 

  Cinoque 16/03/2016 at 14:40

  Tout d’abord, merci pour le chouette article (et le boulot abattu pour rendre le Python abordable).

  Mais bon sang, pourquoi ne pas mentionner la possibilité d’étendre le PYTHON PATH via la variable d’environnement $PYTHONPATH ?

  A la manière du CLASSPATH en Java, un petit coup de :

  export PYTHONPATH=”${PYTHONPATH}:/my/other/path”

  et bim : mon problème était résolu. Bon OK, j’ai appris plein de trucs intéressants en lisant l’article.

  :-P

• 

  Sam Post author 16/03/2016 at 17:48

  Parce que je pense qu’en 2013 je ne savais pas encore qu’on pouvait le faire :)

• 

  HANABI 03/05/2016 at 18:21

  Mais du coup comment on fait pour exécuter un package ?

• 

  Sam Post author 04/05/2016 at 14:22

  Excuter ?

• 

  landry 10/06/2016 at 18:42

  bonjour,

  voila j’ai un souci avec un fichier python et gnuradio qui je pense doit venir d’un problème de destination de block je ne sais pas comment remédier a se problème voici l’erreur

  <<< Welcome to GNU Radio Companion 3.7.9.2 >>>

  Preferences file: /home/landry/.gnuradio/grc.conf

  Block paths:

  /home/landry/.grc_gnuradio

  /usr/local/share/gnuradio/grc/blocks

  Loading: “/home/landry/Bureau/transmit/……._tx.grc”

  Done

  Showing: “/home/landry/Bureau/transmit/……_tx.grc”

  Generating: ‘/home/landry/Bureau/transmit/……_tx.py’

  Executing: /usr/bin/python2 -u /home/landry/Bureau/transmit/……_tx.py

  linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-216-gb1c2d4bb

  gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.2

  built-in sink types: uhd hackrf bladerf redpitaya file

  FATAL: No supported devices found to pick from.

  Trying to fill up 1 missing channel(s) with null sink(s).

  This is being done to prevent the application from crashing

  due to gnuradio bug #528.

  No such file or directory

  Traceback (most recent call last):

  File “/home/landry/Bureau/transmit/…….._tx.py”, line 182, in

  main()

  File “/home/landry/Bureau/transmit/…….._tx.py”, line 176, in main

  tb = top_block_cls(args=options.args, freq=options.freq, freq_offs=options.freq_offs, in_file=options.in_file, out_file=options.out_file, oversample=options.oversample, ppm=options.ppm)

  File “/home/landry/Bureau/transmit/……._tx.py”, line 71, in init

  self.blocks_file_source_0 = blocks.file_source(gr.sizeof_char*1, in_file, False)

  File “/usr/local/lib/python2.7/dist-packages/gnuradio/blocks/blocks_swig0.py”, line 996, in make

  return _blocks_swig0.file_source_make(*args, **kwargs)

  RuntimeError: can’t open file

  Done (return code 1)

  cordialement,

  landry

• 

  Sam Post author 13/06/2016 at 08:42

  Bonjour, veuillez posez votre question sur indexerror.net

• 

  Armand Benoit 29/09/2016 at 08:23

  Bonjour !

  Petite question sur les import (je suis sur info s’en étape s’pas) : si je bosse à un endroit -mettons G:\racinedemonscript- et que je veux importer un module depuis autre part que mon script ou le répertoire site-package de python -mettons D:\Mes Documents-, est-ce possible ?

  J’ai essayé plusieurs trucs de type sys.path.append(“D:\Mes Documents”)

  Import mon module

  ou encore

  Sys.path.append(“D:\Mes Documents”)

  From package import monModule (en créant un package bien sûr)

  Mais ça ne fonctionne pas :(

  Merci de votre aide, le site est super !

  • 

    Sam Post author 01/10/2016 at 08:59

    Poste ta question sur indexerror.net, ça sera plus facile de t’aider là bas.

• 

  lilix50 10/10/2016 at 15:35

  Bonjour

  j aime tes articles j apprends et je me marre bien :)

• 

  Sam Post author 11/10/2016 at 08:34

  :)

• 

  StarNab 04/06/2017 at 09:31

  Mdr cette phrase m’a tué déjà

  “Vous avez donc décidé de vous remettre à PHP, au moins le include utilise les chemins de fichiers, et ça, c’est facile.”

• 

  Florian 15/05/2018 at 07:27

  Salut !

  Tu parles d’une solution avec manage.py, qui sert de script et permet qu’une entrée unique pour le programme.

  J’ai essayé de faire cette solution mais tu mets quoi dans ce fichier manage.py ?

  PS : J’avais essayé en y important les packages (de mon projet)

• 

  Sam Post author 15/05/2018 at 10:47

  Non, manage.py c’est le fichier typique d’une application django. Le point important n’est pas le fichier, mais le fait de toujours lancer Python depuis la racine du projet.

Comments are closed.