Sous unix, le fichier ~/.ssh/config est votre ami, rajoutez lui :

Host Un alias pour l'host
HostName Une IP ou un nom de domaine pour l'host
User votre nom d'utilisateur
IdentityFile le fichier de clé public à utiliser

Par exemple :

Host bitbucket.org
HostName bitbucket.org
User sam
IdentityFile ~/.ssh/sam.pub

Host local-dev
HostName 192.169.0.10
User dev
IdentityFile ~/.ssh/local-dev.pub

On peut créer plusieurs Host pour le même hostname, avec des résultats intéressant quand on a plusieurs identités en ligne.

Créer un fichier “settings_test.py” à côté du fichier de settings, qui contient ça:

from settings import *
 
DATABASES['default'] = {
    'ENGINE': 'django.db.backends.sqlite3',
    'NAME': ':memory:',
}

Et lancer les commandes ./manage.py avec --settings=settings_test :

Par exemple :

./manage.py shell --settings=settings_test
 
./manage.py runserver --settings=settings_test

Et voilà, toute manipulation va automatiquement sauvegarder les données en mémoire vive, et pas dans votre base de données initiale. Elles seront perdues à chaque redémarrage.

D’une manière générale, souvenez vous que vous pouvez faire autant de configurations alternatives et même dynamiques que vous le souhaitez avec les fichiers de settings : c’est juste du Python.

Si vous avez besoin des données de votre base de données initiale, vous pouvez faire une copie de la base de données et changer DATABASES pour pointer sur cette copie. Du coup vous manipulerez votre copie, et pas la base de données initiale.

Enfin, on peut manipuler plusieurs bases de données en même temps en faisant plusieurs entrées dans DATABASES (une ‘default’, une ‘test’, une ‘prod’, etc), par exemple :

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'USER': 'postgres',
        'PASSWORD': 'secret of mana'
    }
    'test': {
    'ENGINE': 'django.db.backends.sqlite3',
    'NAME': ':memory:',
    }
}

On peut alors spécifier la base de données à utiliser, soit par paramètre de ./manage.py (--database=bdd_a_utiliser), soit directement dans le code de manipulation de l’ORM avec using :

>>> Model.objects.all() # tape dans le BDD par défaut
>>> Model.objects.using('test').all() # tape dans la bdd de test
>>> mon_model.save(using='test') # sauvegarde dans la bdd de test

Non ?

Mais je maintiens ce que je dis depuis le début : ce n’est pas un pas en avant.

D’abord, qui dit CBV dit référence constante à la documentation. J’ai été productif avec CBV parce que :

• Je connais l’API Django sur le bout des doigts.
• Je comprends parfaitement les CBV (et la POO en Python en général).
• Je lis très vite, et j’ai l’habitude de fouiller dans les docs.
• Je me balade dans le code source naturellement.

Mais ce n’est pas comme ça que c’est censé être. Si vous utilisez une belle API, comme requests ou path.py, vous n’avez PAS besoin de tout cela. Vous jetez un coup d’œil à la doc, et vous faites 80% du boulot dans le shell, puis de temps à autre, vous vous référez à la documentation sur les points ambiguës. Je n’ai jamais du aller dans le code source de requests, je n’ai jamais eu besoin de comprendre urllib de fond en comble pour utiliser requests, et je n’ai pas besoin de connaître les subtilités de plusieurs paradigmes de programmation pour utiliser requests.

Alors oui, requests ne peut en aucun cas être comparé à Django en terme de taille et de couverture de besoin, et certes, en tant que professionnel averti, je suis tenu d’être capable de faire tout cela. Mais il y a quand même une énorme différence d’effort à fournir, et de qualification à avoir, pour l’usage de cette techno.

En prime, il est TRÈS difficile de débugger une CBV :

• Dans une vue générique sous forme de fonction, on peut juste faire import ipdb, et faire un step puis débugger tranquillement. Dans une CBV, vous le mettez où le break point ? Soit vous overridez une méthode (et il faut savoir par cœur laquelle), soit vous faites un wrapper provisoir sous forme de fonction (!), soit vous mettez le break cash dans le code source de la lib. C’est nul à chier, et improductif. Et certainement pas à la portée d’un débutant.
• Les mixins ont un tas de comportements implicites, qu’il faut connaître pour comprendre pourquoi ceci fait cela. Et comme il y a généralement 3 ou 4 mixins (d’ailleurs, combien de dev peuvent donner la définition d’un mixin ?), et bien si il y a un problème, il y a 4 sources possibles. Qui héritent parfois d’autres classes, ce qui démultiplie le truc.
• Quand ça plante le stack trace est blindée de références à droite et à gauche. Un putain de labyrinthe.

Rajoutez à cela que la syntaxe est verbeuse comme c’est pas permis :

def get_context_data(self, *args, **kwargs):
    context = super(MaClass, self).get_context_data(*args, **kwargs)
    context['ma_var'] = "ma valeur"
    return context

Pour rajouter UNE variable dans le contexte ? Rhaaaaaaaaaaa. Je code en Python, pas en Java !

Et terminez sur le fait que pour utiliser tous les décorateurs codés depuis 5 ans, vous avez une syntaxe bien pourrie ou alors des réimplementations complètes sous forme de mixins. Yeah !

Vous comprendrez que ça me gonfle.

Tout ça pour quel gain ? Oui on gagne un peu en flexibilité, mais ça ne compense pas tout le reste, et ça ne permet en rien de faire des choses qu’on ne pouvait pas faire avant.

Je n’ai pas vu encore la moindre utilisation des CBV qui me fasse dire, “putain c’est tellement mieux qu’avant pour cette partie”. Ni aucune lib qui me fasse dire : “ouais, on aurait pas pu le faire aussi bien avec des vues sous forme de fonctions”.

Avec les CBV devenant la manière par défaut de coder les vues en Django, le framework devient beaucoup moins accessible au débutant, alors que sa facilité d’usage était un de ses points forts.

Bref, je suis de l’avis de Nick Coghlan, les CBV ne sont pas une erreur, elles ont leur utilité, mais balancer à la poubelle les vues sous forme de fonction est une vaste connerie.

Je déjeune avec une très ancienne amie d’enfance, chanteuse lyrique de métier, glamour, voir cul-cul, bobo bio récupérant ses meubles dans les poubelles, amatrice de chats, d’une grande gentillesse, le sourire tendre servi avec des tâches de rousseur. Bref, pas la Paris Hilton de base.

Sam : “En fait tu considères que ta carrière décolle vraiment quand ? Quand tu n’as plus besoin de faire d’auditions ?”

Coraline : “Plutôt quand tu es payée ce que tu dois être payée pour ton travail. Les auditions, ça n’a rien à voir. Moi je galère toujours. Tu te souviens de mon amie Pascaline ? Celle qui a couché avec < Insérer ici le nom d'un grand ténor >. Dans la foulée elle a eu 3 auditions avec 3 des plus grandes maisons de Paris. Il faudrait que j’apprenne à faire comme elle.”

“Au moins vous les filles, vous pouvez faire ça. Nous on peut même pas coucher pour réussir.” (Sauf avec les gays, mais j’y ai pas pensé sur le coup. Remarque je devrais peut être tenter la cougar.)

“Attend, c’est le minimum. Déjà elle couche avec lui, c’est normal qu’il fasse quelque chose pour elle. Elle a pu se faire écouter par une agence qui m’a répondu qu’ils n’avaient plus le temps d’écouter personne. Comme ça, sur un coup de fil du mec. Moi je suis pour, hein. Si le mec te plaît pas, non, mais si il te plaît, y a pas de raison. J’avais un prof de chant qui me disait ‘Il faut coucher utile. Agréable, mais utile.’”

FEMA, où es-tu ?

Voici ce que j’ai dans mon ./.config/ipython/profile_default/ipython_config.py:

c.TerminalIPythonApp.exec_lines = [
'doctest_mode on',
'from __future__ import unicode_literals, absolute_import, division',
'import sys',
'import os',
'import re',
'import json',
'import base64',
'import calendar',
'import csv',
'import datetime',
'import itertools',
'import random',
'import hashlib',
'import tempfile',
'import argparse',
'import math',
'import random',
'import subprocess',
'from glob import glob',
'from uuid import uuid4',
'from datetime import datetime, timedelta',
'from collections import Counter, OrderedDict',
"""
def initial_imports():
 
    # ne faites pas ça dans un code de prod :-)
    global path, relativedelta, requests 
 
    print("\\nImported : 'sys', 'os', 're', 'json', 'base64', 'calendar', 'csv', 'datetime', 'itertools', 'random', 'hashlib', 'tempfile', 'argparse', 'math', 'random', 'glob', 'uuid4', 'datetime', 'timedelta', 'Counter', 'OrderedDict', 'subprocess'\\n")
 
    try:
        from path import path
        print('Imported : "path"')
    except ImportError:
        print("'path' is not available")
 
    try:
        from dateutil import relativedelta
        print('Imported : "relativedelta"')
    except ImportError:
        print("'dateutil' is not available")
 
    try:
        import requests
        print('Imported : "requests"')
    except ImportError:
        print("'requests' is not available")
 
    try:
        env = os.environ['VIRTUAL_ENV']
        print("\\nENV '{}'. You can import:\\n".format(os.path.basename(env)))
        cmd = subprocess.check_output([env + "/bin/pip", "freeze"],
                                      stderr=subprocess.STDOUT).strip().split("\\n")
        p = re.compile(r'(^.*\:\s)|((#|@).*$)|(==.*$)')
        print("'" + "', '".join(sorted(set(os.path.basename(p.sub('', f)) for f in cmd))) + "'")
    except KeyError:
        pass
 
    print('')
""",
"initial_imports()"
]

Du coup, au démarrage d’iPython j’ai les bénéfices suivant :

• Comportement de Python 3 pour l’unicode, les imports et la division. Ils sont plus sains et facile à manipuler (plus besoin de préfixer de ‘u’ les chaînes par exemple).
• J’ai tout de suite sous la main une tonne de modules que j’utilise souvent sans avoir à les importer (os, datetime, random, etc).
• J’importe aussi des modules optionnels (path, requests…).
• Je sais si je suis dans un environnement virtuel, et si oui, ce qu’il y a installé dedans.

Je vire aussi la bannière de démarrage :

c.TerminalIPythonApp.display_banner = False

Et hop, mon affichage au démarrage ressemble à ça :

$ ipython
Exception reporting mode: Plain
Doctest mode is: ON

Imported : 'sys', 'os', 're', 'json', 'base64', 'calendar', 'csv', 'datetime', 'itertools', 'random', 'hashlib', 'tempfile', 'argparse', 'math', 'random', 'glob', 'uuid4', 'datetime', 'timedelta', 'Counter', 'OrderedDict', 'subprocess'

'path' is not available
'dateutil' is not available
Imported : "requests"

ENV 'my_env'. You can import:

'BeautifulSoup', 'Django', 'Fabric', 'Jinja2', 'Pillow', 'Pygments', 'Sphinx', 'URLObject', 'Werkzeug', 'argparse', 'beautifulsoup4', 'colorlog', 'distribute', 'django-appconf', 'django-bootstrap-pagination', 'django-bootstrap-toolkit', 'django-compressor', 'django-debug-toolbar', 'django-extensions', 'django-guardian', 'django-loginas', 'django-model-utils', 'django-pdb', 'django-pytest', 'django-rest-framework.git', 'django-template-repl', 'docutils', 'easy-thumbnails', 'feedparser', 'gunicor

Ça fait un gros bloc visuellement, mais ça ne s’affiche qu’une fois, et le délai est acceptable.

Si j’ai besoin de l’info à nouveau, je peux toujours appeler :

initial_imports()

Que ce genre de choses soient possibles et faciles me font adorer Python. La force du langage, ce n’est pas seulement son core, c’est tout son environnement, ses libs, ses outils qui gravitent autour qui rendent l’expérience de dev fantastique.

Un callable, qu’on peut traduire maladroitement par “appelable”, est un objet qui peut être appelé. Et ça ne vous arrange pas beaucoup de savoir ça.

On parle de callable dans les tutos, les docs, etc, en supposant que vous savez ce que ça veut dire.

En fait c’est très simple, si vous pouvez mettre deux parenthèses après le nom d’un objet (en fait de la variable qui contient l’objet, mais ne chipotons pas) pour obtenir un effet, alors l’objet est un callable.

Une fonction est un callable:

>>> def fonction():
...     print("Vous m'avez appelé")
...
>>> fonction() # appel de la fonction
Vous m'avez appelé

Une classe est un callable:

>>> Class() # appel de la classe
<__main__.Class object at 0x26d8310>

Une méthode est un callable :

>>> class Class(object):
def methode(self):
print("Veuillez patientez, nous allons répondre à votre appel")
...
>>> obj = Class()
>>> obj.methode() # appel de la méthode
Veuillez patientez, nous allons répondre à votre appel

Il sont callables car on peut faire () dessus, et il se passe quelque chose. On peut les appeler.

Et par voie de conséquence, un callable peut retourner une valeur quand il est appelé. En fait, un callable est même garanti de retourner une valeur quand il est appelé, puisque toute fonction ou méthode retourne None par défaut en Python, et toute classe retourne au moins un objet vide.

Les string, les int, les listes, les fichiers ou les dicos ne sont pas des callables :

>>> 1()
Traceback (most recent call last):
File "<ipython-input-11-769e123a5ede>", line 1, in <module>
1()
TypeError: 'int' object is not callable
 
>>> ""()
Traceback (most recent call last):
File "<ipython-input-12-de235e3e26d7>", line 1, in <module>
""()
TypeError: 'unicode' object is not callable
 
>>> []()
Traceback (most recent call last):
File "<ipython-input-13-bda5b10b5bf7>", line 1, in <module>
[]()
TypeError: 'list' object is not callable
 
>>> {}()
Traceback (most recent call last):
File "<ipython-input-14-67901a4bc3e8>", line 1, in <module>
{}()
TypeError: 'dict' object is not callable
 
>>> f = open('/etc/fstab')
>>> f()
Traceback (most recent call last):
File "<ipython-input-16-0ec059b9bfe1>", line 1, in <module>
f()
TypeError: 'file' object is not callable

Mais les classes (et oui, ce sont des classes, pas des fonctions malgré leurs noms en minuscule) str, int, list, dict et file sont des callables :

>>> int()
0
>>> str()
''
>>> dict()
{}
>>> list()
[]
>>> file('/etc/fstab')
<open file u'/etc/fstab', mode 'r' at 0x2689930>

En fait, la plupart des objets ne sont tout simplement pas des callables. Aucun nouvel objet n’est un callable par nature.

>>> obj = Class()
 
>>> obj()
Traceback (most recent call last):
File "<ipython-input-18-da8742d08647>", line 1, in <module>
obj()
TypeError: 'Class' object is not callable

Donc, quand on vous dit de passer un “callable” en paramètre, généralement on vous dit de passer une fonction (sans les parenthèses), une classe (sans les parenthèses) ou une méthode (sans les parenthèses), afin de s’en servir comme callback.

Par exemple, les champs des modèles Django acceptent un callable comme paramètre par défaut. Comme les callables sont garantis de retourner une valeur, Django utilise cela pour créer dynamiquement une valeur par défaut. La fonction sort() des listes accepte un callable en callback pour le paramètre key.

Demander un callable, c’est donc demander un truc qu’on peut appeler en utilisant des parenthèses, et qui va retourner un autre truc.

Au passage, pour votre culture, on peut créer ses propres callables. Ça sert rarement, dans quelques cas tordus. Il suffit de créer une classe avec la méthode magique __call__, et l’objet retourné sera automatiquement un callable :

>>> class CreerUnCallable(object):
...         def __call__(self):
...                 return "Vous m'avez appelé, maître ?"
...
>>> un_callable = CreerUnCallable()
>>> print(un_callable())
Vous m'avez appelé, maître ?

On a donc ici DEUX callables : la classe, qui est callable par nature, et l’instance de la classe, qui est callable grâce à la méthode __call__.

Et moi j’ai commencé à taper cet article parce que je me suis dit que c’était une notion simple et que ça allait être vite fait, juste avant le petit dèj. Ca fait une heure que je suis dessus. Qu’est-ce que je suis con des fois.

J’ai aussi updaté la copie offline du site pour que vous puissiez en profiter dans le train, au camping, chez mamie, etc.

Enjoy.

Les imports, c’était fastoche. Vous étiez dans votre petit programme, et pour importer un module de la lib standard, vous faisiez:

import module

Par exemple :

import os

Et pour importer une classe ou une fonction de cette lib, vous faisiez :

from module import fonction
from module import Classe

Par exemple :

from hashlib import md5
from xml.etree import Element

Parfois, c’était un peu plus compliqué, mais ça allait encore. Des fois il fallait importer un sous-module :

from package.sous_package import module

Par exemple :

from xml.sax import saxutils

Mais ça allait encore.

Et puis un jour vous avez du écrire votre propre module. Vous n’aviez pas vraiment réfléchi à la question. C’était juste une petite lib pour regrouper des fonctions. Ou juste une app Django. Un truc tout simple. Mais les imports ont soudainement cessé de devenir clairs. Ça ne marchait pas. Rien ne marchait. Vous aviez des sys.path.append partout juste au cas où et c’était encore pire.

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

Sous le capot

Quand vous utilisez import, sous le capot Python utilise le fonction __import__. Malgré ses __ dans le nom, c’est une fonction ordinaire, et vous pouvez d’ailleurs l’utiliser vous-même :

>>> os = __import__('os')
>>> os.path.join('s', 'ton', 'mon', 'g')
u's/ton/mon/g'

En fait, importer un module, c’est créer un objet module qui est assigné à une variable tout à fait normale :

>>> type(os)
<type 'module'>
>>> os = "on peut ecraser un module"
>>> os.path
Traceback (most recent call last):
  File "<ipython-input-12-e34748f24345>", line 1, in <module>
    os.path
AttributeError: 'unicode' object has no attribute 'path'
 
>>> import sys
>>> type(sys)
<type 'module'>
>>> sys = "je t'ecrase la tronche"
>>> type(sys)
<type 'unicode'>

Le mécanisme de module Python n’est donc pas un truc à part, c’est un objet comme le reste, qui contient des attributs. Les attributs sont les variables et les fonctions du module.

Pour charger un module, la fonction __import__ passe par les étapes suivantes :

1. Chercher si le module os existe.
2. Chercher si le module a déjà été importé. Si oui, s’arrêter ici et renvoyer le module existant.
3. Si non, chercher si il a été déjà compilé en .pyc.
4. Si ce n’est pas le cas, compiler le fichier .py en .pyc.
5. Charger le bytecode du fichier pyc.
6. Créer un objet module vide.
7. Éxecuter le bytecode dans le contexte de l’objet module et remplir ce dernier avec le résultat.
8. Ajouter l’objet module dans sys.modules, un dictionnaire qui contient tous les modules déjà chargés.
9. Retourner le module pour pouvoir l’assigner à une variable, par défaut la variable porte son nom.

La fonction __import__ est donc très complexe, et d’ailleurs si vous voulez l’utiliser pour des trucs plus compliqués qu’un simple import de module, vous allez galérer car sa signature est vraiment zarb.

Mais pour vous, seule l’étape 1 est importante à comprendre. C’est l’étape à laquelle tout se joue.

Comment Python définit quel module importer ?

C’est la partie vraiment difficile, en effet si un import ne marche pas, c’est très souvent parce que Python ne trouve pas le module que vous voulez. Et la raison pour laquelle il ne le trouve pas, c’est que vous ne comprenez pas comment il cherche.

Python utilise ce qu’on appelle le PYTHON PATH pour chercher les modules importables. C’est une variable système qui contient une liste de dossiers. Par exemple, sur ma machine, elle contient ceci :

['',
 '/usr/bin',
 '/usr/local/lib/python2.7/dist-packages/grin-1.2.1-py2.7.egg',
 '/usr/lib/python2.7',
 '/usr/lib/python2.7/plat-linux2',
 '/usr/lib/python2.7/lib-tk',
 '/usr/lib/python2.7/lib-old',
 '/usr/lib/python2.7/lib-dynload',
 '/home/sam/.local/lib/python2.7/site-packages',
 '/usr/local/lib/python2.7/dist-packages',
 '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info',
 '/usr/lib/python2.7/dist-packages',
 '/usr/lib/python2.7/dist-packages/PIL',
 '/usr/lib/python2.7/dist-packages/gst-0.10',
 '/usr/lib/python2.7/dist-packages/gtk-2.0',
 '/usr/lib/pymodules/python2.7',
 '/usr/lib/python2.7/dist-packages/ubuntu-sso-client',
 '/usr/lib/python2.7/dist-packages/ubuntuone-client',
 '/usr/lib/python2.7/dist-packages/ubuntuone-control-panel',
 '/usr/lib/python2.7/dist-packages/ubuntuone-couch',
 '/usr/lib/python2.7/dist-packages/ubuntuone-installer',
 '/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol',
 '/usr/lib/python2.7/dist-packages/wx-2.6-gtk2-unicode',
 '/usr/lib/python2.7/dist-packages/IPython/extensions']

Donc, quand vous faites import os, Python va faire une boucle for là dessus et chercher dans chaque dossier si un package (un dossier avec un fichier __init__.py) ou un module (un fichier avec l’extension .py) nommé os existe.

Dès qu’il en trouve un, il s’arrête de chercher et l’importe. Si il n’en trouve pas, il va lever une ImportError.

Ce qui signifie que si votre module n’est PAS dans le PYTHON PATH, vous ne pouvez PAS l’importer. C’est impossible.

La grande majorité des problèmes d’import vient du fait que le module que vous essayez d’importer n’est pas dans le PYTHON PATH.

Maintenant, la grande question, c’est :

Qu’est-ce qui est dans le PYTHON PATH ?

Par défault, les dossiers sites-packages et dist-packages dans le dossier d’installation Python sont dans le PYTHON PATH. Quelques autres sont ajoutés selon les systèmes, mais vous pouvez toujours compter sur sites-packages et dist-packages pour être dans le PYTHON PATH. Quand vous installez une lib, par exemple avec pip, c’est là dedans que la lib va s’installer, pour être sûre de pouvoir être importée.

Quand vous êtes dans un virtualenv, les dossiers sites-packages et dist-packages de l’environnement virtuel sont ajoutés au PYTHON PATH.

Mais tout ça ne change pas grand chose pour vous. En effet, vous n’allez pas mettre VOTRE code dans les dossiers sites-packages et dist-packages.

C’est pour cela que Python possède un mécanisme supplémentaire : le dossier qui contient le module sur lequel vous lancez la commande python est automatiquement ajouté au PYTHON PATH.

Le PYTHON PATH, en pratique

Supposons que je sois dans le dossier /home/sam/Bureau et que j’aie dedans ce package. Voici à quoi ressemble mon arbo (téléchargez l’arbo vierge pour vos tests):

/home/sam/Bureau # <-- je suis ici
.
`-- test_imports
    |-- __init__.py
    |-- package_tout_en_haut
    |   |-- __init__.py
    |   |-- autre_sous_package
    |   |   |-- __init__.py
    |   |   `-- autre_module_en_bas.py
    |   |-- sous_module.py
    |   `-- sous_package
    |       |-- __init__.py
    |       |-- autre_module_en_bas.py
    |       |-- autre_sous_package
    |       |   |-- __init__.py
    |       |   `-- autre_module_en_bas.py
    |       `-- module_tout_en_bas.py
    `-- top_module.py

Si je lance un shell Python depuis ce dossier ou un script Python contenu dans ce dossier, je peux faire import test_imports, car /home/sam/Bureau est automatiquement ajouté au PYTHON PATH.

Je peux donc faire :

>>> import test_imports
>>> from test_imports import package_tout_en_haut
>>> from test_imports import top_module
test_imports.top_module
>>> from test_imports.package_tout_en_haut import sous_module
test_imports.package_tout_en_haut.sous_module

Mais si je me mets ici dans ./package_tout_en_haut/sous_package :

/home/sam/Bureau
.
`-- test_imports
    |-- __init__.py
    |-- package_tout_en_haut
    |   |-- __init__.py
    |   |-- autre_sous_package
    |   |   |-- __init__.py
    |   |   `-- autre_module_en_bas.py
    |   |-- sous_module.py
    |   `-- sous_package     # <-- je suis ici
    |       |-- __init__.py
    |       |-- autre_module_en_bas.py
    |       |-- autre_sous_package
    |       |   |-- __init__.py
    |       |   `-- autre_module_en_bas.py
    |       |-- module_tout_en_bas.py
    `-- top_module.py

Je ne peux PAS importer test_imports, ni dans un shell, ni depuis un module de ce dossier :

>>> import test_imports
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named test_imports

En effet, comme je lance la commande Python depuis

./package_tout_en_haut/sous_package

alors

./package_tout_en_haut/sous_package

EST ajouté au PYTHON PATH, mais

/home/sam/Bureau/

n’est PAS ajouté au PYTHON PATH.

Je ne peux donc PAS faire

from test_imports import top_module

depuis un fichier comme

.test_imports/package_tout_en_haut/sous_package/autre_module_en_bas.py

et exécuter directement

python autre_module_en_bas.py

ni même

python ./test_imports/package_tout_en_haut/sous_package/autre_module_en_bas.py

Je peux faire

from test_imports import top_module

depuis

autre_module_en_bas.py

uniquement si je lance un script Python tout en haut de mon arbo qui importe

autre_module_en_bas.py.

Mais alors, comment on fait ?

Il faut s’assurer que le dossier qui contient test_imports, notre module racine, soit TOUJOURS dans le PYTHON PATH.

Il y a plusieurs possibilités pour cela.

La première, c’est que notre lib va être utilisée une fois installée avec pip. Dans ce cas, on s’en branle, test_imports sera dans sites-packages automatiquement, et on pourra faire from test_imports import top_module de partout joyeusement.

Mais souvent, ce n’est pas le cas, votre code n’est pas fait pour être installé.

La seconde technique consiste à s’assurer que l’on appelle TOUJOURS la commande Python depuis le dossier qui est tout au dessus. C’est ce que fait django avec sa commande ./manage.py par exemple.

Vous avez votre projet :

./manage.py
projet

Et tout passe par python manage.py, qui est au dessus de projet, donc le dossier est bien ajouté au PYTHON PATH, et tout va bien.

Dans votre cas ça veut dire vous assurer qu’on lance toujours votre programme depuis un script d’entrée qui est tout en haut de votre arborescence.

Ca veut dire que vous devez avoir un point d’entrée UNIQUE pour votre package.

Mais parfois ça ne convient pas. Dans le cas des tests unitaires par exemple, il vous faut un point d’entrée spécialement pour les tests.

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.

La manière dont vous organisez votre projet est donc très importante en Python, et si vous avez des problèmes d’import, la première chose à faire est de changer sa structure. Il n’y a pas de magie.

La dernière possibilité, quand tout a échoué, c’est de rajouter à la main le dossier dans le PYTHON PATH. sys.path est une simple liste, on peut donc faire un append() dessus.

Par exemple, si je veux absolument (mais je ne devrais pas :-)) pouvoir faire :

python .test_imports/package_tout_en_haut/sous_package/autre_module_en_bas.py et importer test_imports dans autre_module_en_bas.py, je peux faire un truc du genre :

import os
 
dossier = os.path.dirname(os.path.abspath(__file__))
 
while not dossier.endswith('test_imports'):
    dossier = os.path.dirname(dossier)
 
dossier = os.path.dirname(dossier)
 
if dossier not in sys.path:
    sys.path.append(dossier)

Ce code va remonter dans l’arbo jusqu’à tomber sur le chemin du dossier test_imports et ajouter son dossier parent au PYTHON PATH.

Ce n’est pas le truc le plus propre du monde, mais ça peut dépanner.

Imports absolus et relatifs

Si vous êtes dans ./package_tout_en_haut/sous_package :

/home/sam/Bureau
.
`-- test_imports
    |-- __init__.py
    |-- package_tout_en_haut
    |   |-- __init__.py
    |   |-- autre_sous_package
    |   |   |-- __init__.py
    |   |   `-- autre_module_en_bas.py
    |   |-- sous_module.py
    |   `-- sous_package     # <-- je suis ici
    |       |-- __init__.py
    |       |-- autre_module_en_bas.py
    |       |-- autre_sous_package
    |       |   |-- __init__.py
    |       |   `-- autre_module_en_bas.py
    |       |-- module_tout_en_bas.py
    |       `-- test_imports  # <-- autre package nommé test_imports
    |           `-- sous_module.py
    `-- top_module.py

Vous voyez que vous avez deux packages nommés test_imports.

Si vous écrivez import test_imports dans autre_module_en_bas.py, que va-t-il se passer ?

C'est le module tout en bas qui va être importé.

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

En faisant cela, vous obtenez le comportement de Python 3 dans Python 2.7, et vous pourrez alors choisir entre faire :

import test_imports # importe le module tout en haut
import .test_imports # import le module dans le même dossier
from .test_imports import sous_module
from test_imports import top_module

Je vous recommande de toujours utiliser from __future__ import absolute_import. Ca ne coûte rien, et c'est plus cohérent. Par contre, vous ne pourrez pas tester from __future__ import absolute_import dans le shell, donc cet exemple ne marche pas dans ipython, mais il fonctionne parfaitement dans vos modules.

On peut aussi faire des imports relatifs du package contenant avec :

from .. import truc
from ..package import machin

N'oubliez pas que ceci ne marche que :

• Si from __future__ import absolute_import est activé.
• Le package tout en haut (celui qui contient tous les autres) est dans le PYTHON PATH

Sinon, ça ne sert A RIEN. Ce n'est pas comme un ../ dans un bash. Ça ne remonte pas d'un dossier. C'est juste une notation pour dire j'utilise celui la plutôt que l'autre, quand il y a ambiguité.

Pièges des imports

Package sans init

Si vous avez :

.
`-- test_imports
    |-- __init__.py
    |-- package_sans_init
    |   `-- nada.py

nada.py n'est pas importable, car package_sans_init ne contient pas de fichier __init__.py, même si test_imports est dans le PYTHON PATH. Ce comportement est corrigé en Python 3, et tout sous-dossier d'un package importable est automatiquement importable, qu'il contienne un __init__.py ou non.

Imports circulaires

J'en ai déjà parlé ici.

Vous avez :

.
`-- test_imports
    |-- __init__.py
    |-- package_tout_en_haut
    |   |-- __init__.py
    |   `-- sous_package
    |       |-- __init__.py
    |       |-- autre_module_en_bas.py
    |       `-- module_tout_en_bas.py

Et vous importez autre_module_en_bas dans module_tout_en_bas et inversement. Non seulement ça ne marchera pas, mais en plus l'erreur est déroutante :

ImportError: No module named module_tout_en_bas

Oui vous avez bien lu, il va vous dire que le module n'existe pas !

Il n'y a pas non plus de solution propre à ce problème : soit vous fusionnez vos deux fichiers, soit vous faites un 3eme module qui utilise ces deux modules (et ces deux modules n'importent pas ce 3eme module).

Sinon il y a la solution crade : mettre un des imports dans un appel de fonction ou de méthode comme ça:

def truc():
    import module_tout_en_bas
    module_tout_en_bas.bidule()

Parfois, ça dépanne :-) On ne tue pas des chatons non plus, donc si ça ne devient pas une habitude, ça peut passer.

1. Installation

Pour installer le service ntp, ouvrez un terminal en root.

Sous Ubuntu:

sudo apt-get install ntp

2. Utilisation

La configuration de ntp se trouve généralement dans le fichier /etc/ntp.conf. On peut y ajouter de nouveaux serveurs de temps, en ajoutant une ligne similaire à celle-ci par exemple :

server 0.fedora.pool.ntp.org dynamic

Démarrez ensuite le service avec cette commande afin de synchroniser la date et l’heure (Attention, il faut plusieurs minutes avant que l’heure soit synchronisée) :

/etc/init.d/ntpd start

On pourra ensuite vérifier que l’heure est correcte avec la commande “date”:

[sm@web1 ~]# date
Wed May 15 07:21:15 UTC 2013
[sm@web1 ~]#

Note : en cas de problème, on pourra vérifier le bon fonctionnement avec la commande ntpstat qui donnera des informations sur le statut du service ntp :

[sm@web1 ~]# ntpstat
synchronised to NTP server (213.161.194.93) at stratum 4
time correct to within 562 ms
polling server every 64 s

A quoi ça sert ?

Dans notre cas nous avons des sites qui hébergent du contenu avec des urls qui expirent au bout d’un certainstemps.
La création de ces urls à durée de vie comptée est faite depuis le serveur web, le contenu se trouvant sur d’autres serveurs.
ntp dans ce cas nous assure que tous les serveurs seront calés sur la même heure, ce qui évite de générer des urls déjà expirées si un des serveurs de contenu n’était pas à l’heure.