Je le publie en coup de vent car je me dis que ça peut servir à des gens, mais j’ai pas l’intention d’y passer des heures… vu que je fais ça pour me faire gagner du temps en mission.

J’ai créé devpy, un outil pour me faciliter le développement.

Dans sa forme la plus simple:

pip install devpy

Ca donne automatiquement:

• Un logger qui log dans un fichier temporaire et dans la console.
• Un traceback qui montre les lignes de SON code avec coloration syntaxique.
• Si le programme crashe, la stack trace est logguée dans le log automatiquement.

En gros quand on commence à bosser on fait:

import devpy.develop as log

Et on peut logguer comme avec les logs python habituels (log.info, log.debug, etc).

On peut facilement retirer devpy une fois qu’on a fini et le remplacer par un log Python traditionnel type:

log = logging.getLogger(__name__)

Donc utiliser devpy ne coûte rien car on peut le retirer facilement une fois qu’on a fini: c’est 100% compat avec le log de la stdlib.

Ça tombe bien, car c’est pas un truc qu’on met en prod en théorie (même si ça peut pas abîmer le serveur).

C’est juste un outil que j’ai fait car j’en avais marre:

• De galérer à setuper un logging de base à chaque fois. C’est long, verbeux, plein de coups fourrés. Mais 9 fois sur 10 je veux la même chose: la console et un fichier temp. Du coup par flemme je fais un print et je le regrette plus tard.
• Devoir faire les choses proprement pour le dev. Oui un bon log c’est important, mais quand je commence à bosser je ne veux pas passer mon après-midi à setuper les logs proprement. Je ferai ça plus tard, un truc à l’arrache pour le debug me suffit.
• Devoir chercher dans la stack trace les lignes qui m’intéressent. Je debugge rarement la stdlib. Montre moi MON code.
• Avoir des logs avec la stack trace en cas d’erreur est super relou à mettre en place. Mais c’est tellement pratique.

Je sais, il existe une tetra chiées d’outils de logging pour Python. Mais c’est pas ce que je veux. Je ne veux pas choisir une solution ou configurer un truc. Ca je le ferai plus tard, proprement. Je veux juste un log essentiel et à coût zero pour démarrer mes projets et pouvoir switcher plus tard.

Je vais sûrement rajouter des trucs dans devpy au fur et à mesure mais pour le moment ça fait ce que je veux.

Je l’ai mis compatible uniquement 3.6 car j’ai pas envie de me faire chier à tester ailleurs. D’ailleurs j’ai même pas de tests.

Et si vous êtes pas contents, vous pouvez vous mettre ma deadline là où je pense.

La toute première version de Python 3.6 avait un bug assez vicieux qui ne se manifestait que sous certaines conditions, généralement dans un daemon sur un serveur, et en important certains modules qui finissent par déclencher par réaction en chaîne l’usage de random.

django est concerné.

On tombait dessus généralement assez tard, à la mise en prod, avec un message cryptique:

 
BlockingIOError: [Errno 11] Resource temporarily unavailable 
  
 The above exception was the direct cause of the following exception: 

Traceback (most recent call last): 
   .... <- des imports de votre code qui ne font rien de mal
   File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 36, in  
     import email.parser 
   File "/usr/local/lib/python3.6/email/parser.py", line 12, in  
     from email.feedparser import FeedParser, BytesFeedParser 
   File "/usr/local/lib/python3.6/email/feedparser.py", line 27, in  
     from email._policybase import compat32 
   File "/usr/local/lib/python3.6/email/_policybase.py", line 9, in  
     from email.utils import _has_surrogates 
   File "/usr/local/lib/python3.6/email/utils.py", line 28, in  
     import random 
   File "/usr/local/lib/python3.6/random.py", line 742, in  
     _inst = Random() 
 SystemError:  returned a result with an error set 

Cela a été corrigé rapidement, et le binaire patché ajoute juste un “+” à sa version:

$ python --version
Python 3.6.0+

En théorie vous ne pouvez pas tomber dessus, tous les liens de téléchargement ont été mis à jour, les distributions ont changé leurs dépôts, etc.

Mais hier je me suis fait bien niqué, et j’ai perdu 1h à debugguer cette surprise qui n’avait aucun sens (puisque mon code allait bien) : les bugs dans les binaires officiels sont rares et c’est le dernier endroit où je cherche.

En effet, certaines sources non-officielles pour installer Python n’ont pas été mises à jour, et c’est le cas du très populaire PPA deadsnakes.

Si vous avez installé Python 3.6 en faisant :

sudo add-apt-repository ppa:fkrull/deadsnakes
sudo apt-get update
sudo apt-get install python3.6

vous l’avez dans le cul.

Il existe un PPA plus à jour si vous avez besoin de corriger le tir :

sudo add-apt-repository ppa:jonathonf/python-3.6
sudo apt-get update
sudo apt-get install python3.6

Donc si vous avez compilé Python à la main ou utilisé un PPA, assurez-vous bien d’avoir la bonne version, et sinon upgradez. En attendant j’ai un bug report à faire à deadsnakes…

On ne veut pas mettre sa SECRET_KEY en prod, et utiliser un service pour générer la clé, ça va deux minutes.

Générer une clé secrète:

import random
import string
 
def secret_key(size=50):
    pool = string.ascii_letters + string.digits + string.punctuation
    return "".join(random.SystemRandom().choice(pool) for i in range(size))

Générer une clé secrete avec une commande manage.py:

from django.core.management.base import BaseCommand, CommandError
from polls.models import Question as Poll
 
class Command(BaseCommand):
    help = 'Generate a secret key'
 
    def add_arguments(self, parser):
        parser.add_argument('size', default=50, type=int)
 
    def handle(self, *args, **options):
        self.stdout.write(secret_key(options['size']))

A mettre dans ./votreapp/management/command/generate_secret_key.py :)

Une fonction pour lire la clé depuis un fichier texte ou générer la clé si elle n’existe pas:

import io
import os
 
try:
    import pwd
except ImportError:
    pass
 
try:
    import grp
except ImportError:
    pass
 
 
def secret_key_from_file(
        file_path, 
        create=True, 
        size=50, 
        file_perms=None, # unix uniquement
        file_user=None, # unix uniquement
        file_group=None # unix uniquement
    ):
    try:
        with io.open(file_path) as f:
            return f.read().strip()
    except IOError as e:
        if e.errno == 2 and create:
            with io.open(file_path, 'w') as f:
                key = secret_key(size)
                f.write(key)
 
            if any((file_perms, file_user, file_group)) and not pwd:
                raise ValueError('File chmod and chown are for Unix only')
 
            if file_user:
                os.chown(file_path, uid=pwd.getpwnam(file_user).pw_uid)
 
            if file_group:
                os.chown(file_path, gid=grp.getgrnam(file_group).gr_gid)
 
            if file_perms:
                os.chmod(file_path, int(str(file_perms), 8))
 
            return key
 
        raise

Et une fonction pour récupérer la clé depuis une variable d’environnement ou un fichier:

def get_secret_key(
        file_path=None, 
        create=True, 
        size=50, 
        file_perms=None, 
        file_user=None, 
        file_group=None,
        env_var="DJANGO_SECRET_KEY"
    ):
    try:
        return os.environ[env_var]
    except KeyError:
        if file_path:
            return secret_key_from_file(file_path, create=create, size=size)
        raise

Le but de cette dernière est d’avoir ça dans son fichier de settings:

SECRET_KEY = get_secret_key('secret_key')

Et de foutre ‘secret_key’ dans son .gitignore.

Comme ça:

• Si on n’a pas de clé secrète, on en génère une.
• Si on a une, elle est dans un fichier qui n’est PAS dans settings.py.
• On peut commiter settings.py. Chaque env de dev et prod a sa clé secrète automatiquement.
• On peut overrider la clé avec une variable d’environnement si on le souhaite.

En attendant, j’ai proposé qu’on ajoute ça a django extensions. Et qui sait, dans le core peut être un jour ?

Si il y a bien une mailing-list à suivre, c’est Python-idea. Elle regorge de tout, on est y apprend sans cesse à propos de Python, la programmation en général, la gestion de communautés, etc. Mais c’est accessible pour peu qu’on soit à l’aise en anglais.

Parmi les sujets chauds du moment, il y a l’introduction, pour potentiellement Python 3.7, d’un mot clé pour évaluer paresseusement les expressions.

Je m’explique…

On a déjà plusieurs moyens de faire du lazy loading en python :

• Le shortcut des opérateurs and et or. La partie droite ne s’exécute que si la gauche ne répond pas déjà à la question.
• Les générateurs. Il ne sont évalués qu’au premier appel de next().
• await : évalué seulement quand la boucle d’événement décide de passer par là.

La nouvelle proposition est quelque chose de différent : permettre de déclarer une expression arbitraire, mais qui n’est évaluée que la première fois qu’on la lit.

Ca ressemble à ça:

def somme(a, b):
    print('coucou')
    return a + b
 
truc = lazy somme(a, b)
print("Hello")
print(truc)

Ce qui afficherait:

Hello
coucou
3

On peut mettre ce qu’on veut après le mot clé lazy. Le code n’est exécuté qu’une fois qu’on essaye d’utiliser la variable truc.

L’usage essentiel, c’est de pouvoir déclarer du code sans chichi, comme si on allait l’utiliser maintenant. Le passer à du code qui va l’utiliser sans même avoir besoin de savoir que c’est un truc spécial. Et que tout marche à la dernière minute naturellement.

Par exemple, la traduction d’un texte dans un code Python ressemble souvent à ça :

from gettext import gettext as _
...
print(_('Thing to translate'))

Mais dans Django on déclare un champ de modèle dont on veut pouvoir traduire le nom comme ceci :

from django.utils.translation import ugettext_lazy
 
class Produit(models.Model):
    ...
    price = models.IntegerField(verbose_name=ugettext_lazy("price"))

La raison est qu’on déclare ce texte au démarrage du serveur, et on ne sait pas encore la langue dans laquelle on va le traduire. Cette information n’arrive que bien plus tard, quand un utilisateur arrive sur le site. Mais pour détecter toutes les chaînes à traduire, créer le fichier de traduction, construire le cache, etc., il faut pouvoir marquer la chaîne comme traductible à l’avance.

Django a donc codé ugettext_lazy et tout un procédé pour évaluer cette traduction uniquement quand une requête Web arrive et qu’on sait la langue de l’utilisateur.

Avec la nouvelle fonctionnalité, on pourrait juste faire:

from gettext import gettext as _
 
class Produit(models.Model):
    ...
    price = models.IntegerField(verbose_name=lazy _("price"))

Rien à coder nulle part du côté de Django, rien à savoir de plus pour un utilisateur. Ça marche dans tous les cas, pareil pour tout le monde, dans tous les programmes Python.

Bref, j’aime beaucoup cette idée qui permet de s’affranchir de pas mal de wrappers pour plein de trucs, mais aussi beaucoup aider les débutants. En effet les nouveaux en programmation font généralement des architectures basiques : pas d’injection de dépendances, pas de factories, etc. Avec lazy, même si une fonction n’accepte pas une factory, on peut quand même passer quelque chose qui sera exécuté plus tard.

Évidement ça ne dispense pas les gens de faire ça intelligemment et d’attendre des callables en paramètre. Dans le cas de Django, une meilleure architecture accepterait un callable pour verbose_name par exemple.

Mais c’est un bon palliatif dans plein de situations. Et l’avantage indiscutable, c’est que le code qui utilise la valeur paresseuse n’a pas besoin de savoir qu’elle le fait.

Les participants sont assez enthousiastes, et moi aussi, bien que tout le monde a conscience que ça pose plein de questions sur la gestion des générateurs, de locals(), et du debugging en général.

Plusieurs mots clés sont actuellement en compétition: delayed, defer, lazy. delayed est le plus utilisé, mais j’ai un penchant pour lazy.

Viendez sur la mailing list !

Ça faisait un bail que j’avais pas parlé d’un don du mois. Le don du mois n’est pas un don mensuel, mais un don que je fais pour le mois. Des fois j’oublie. Des fois je n’ai pas de thune. Des fois je ne me sens pas généreux, que l’humanité aille crever dans sa crasse !

Mais quand les astres du pognon et de la bonne humeur sont alignés je m’y remets.

J’ai pris des nouvelles de nuitka, un outil qui permet de compiler du code Python en un exe indépendant. Malgré le fait que l’auteur soit visiblement le seul à vraiment travailler dessus, le projet continue d’avancer avec régularité et détermination. Corrections de bugs, optimisation (amélioration de la comptabilité (la 3.5 est supportée, la 3.6 en cours !)).

J’ai été agréablement surpris de voir que l’outil s’était encore amélioré. Le hello world stand alone m’a pris quelques minutes à mettre en œuvre, d’autant que nuitka est dans les dépôts Ubuntu donc l’installation ne demande aucun effort.

Comme pouvoir shipper du code Python sans demander à l’utilisateur final d’installer Python est quelque chose qui est en forte demande en ce moment, j’ai voulu soutenir le projet, et j’ai fait un don de 50 euros.

Puis je me suis souvenu qu’en fait, j’en avais déjà fait un l’année dernière :) Bah, l’auteur mérite qu’on le soutienne. Des mecs comme ça y en a pas des masses.