PROJET AUTOBLOG


Sam et Max

source: Sam et Max

⇐ retour index

Le PEP8, en résumé

jeudi 26 décembre 2013 à 20:15

Internet, c’est la culture du TL;DR, donc plutôt je vais faire une petite synthèse des trucs les plus importants du PEP8, comme ça si vous avez la flemme de le lire, au moins vous aurez l’essentiel.

Ce texte liste les règles stylistiques recommandées, invitant toute la communauté Python à écrire un code de la même façon.

Je vais également y ajouter des éléments de style qui ne sont pas dedans, mais que j’ai pu constater comme étant les choix les plus courants dans les sources que j’ai pu lire.

Espaces

Les opérateurs doivent être entourés d’espaces.

Il faut faire ceci :

variable = 'valeur'
 
ceci == cela
 
1 + 2

Et non:

variable='valeur'
 
ceci==cela
 
1+2

Il y a deux exceptions notables.

La première étant qu’on groupe les opérateurs mathématiques ayant la priorité la plus haute pour distinguer les groupes :

a = x*2 - 1
b = x*x + y*y
c = (a+b) * (a-b)

La seconde est le signe = dans la déclaration d’arguments et le passage de paramètres :

def fonction(arg='valeur'): #  ça c'est ok
    pass
 
resultat = fonction(arg='valeur') #  ça aussi

On ne met pas d’espace à l’intérieur des parenthèses, crochets ou accolades.

Oui :

2 * (3 + 4)
 
def fonction(arg='valeur'):
 
{str(x): x for x in range(10)}
 
val = dico['key']

Non :

2 * ( 3 + 4 )
 
def fonction( arg='valeur' ):
 
{ str(x): x for x in range(10) }
 
val = dico[ 'key' ]

On ne met pas d’espace avant les deux points et les virgules, mais après oui.

Oui :

def fonction(arg1='valeur', arg2=None):
 
dico = {'a': 1}

Non :

def fonction(arg='valeur' , arg2=None) :
 
dico = {'a' : 1}

Lignes

Une ligne doit se limiter à 79 charactères. Cette limite, héritée des écrans touts petits, est toujours en vigeur car il est plus facile de scanner un code sur une courte colonne qu’en faisant des aller-retours constant.

Si une ligne est trop longue, il existe plusieurs manières de la racourcir :

foo = la_chose_au_nom_si_long_quelle_ne_tient_pas_sur(
          une, 
          carte, 
          de, 
          munchkin)

Ici l’indentation entre le nom de la fonction et des paramètres est légèrement différente pour mettre en avant la distinction.

Une variante :

foo = la_chose_au_nom_si_long_quelle(ne, tient, pas, sur, carte 
                                     une, de, munchkin)

Si c’est un appel chainé, on peut utiliser \ pour mettre à la ligne :

queryset = ModelDjangoALaNoix.objects\
                             .filter(banzai=True)\
                             .exclude(chawarma=False)

Si c’est une structure de données, on peut se la jouer langage fonctionel de la vibes du flex :

chiffres = [
    1, 2, 3,
    4, 5, 6,
]
 
contacts = {
    'Cleo': (),
    'Ramses': (
        ('maman', '0248163264'),
        ('papa', '01234567890'),
        ('mamie', '55555555'),
        ('momie', '066642424269')
    )
}

Séparer les fonctions et les classes à la racine d’un module par 2 lignes vides. Les méthodes par 1 ligne vide. Parfois je triche et je fais 3 et 2 au lieu de 2 et 1.

Les imports de plusieurs modules doivent être sur plusieurs lignes :

import sys
import os

Et non :

import sys, os

Bien sûr, ce n’est pas valable pour from x import z.

Souvenez-vous qu’on peut utiliser les parenthèses pour diviser de longues lignes. Par exemple :

from minibelt import (dmerge, get, iget, normalize, 
                      chunks, window, skip_duplicates, flatten)

Idem pour les chaînes très longues :

s = ("Les chaînes Python sont automatiquement"
     "concaténées par la VM si elles sont "
     "uniquement séparées par des espaces "
     "ou sauts de lignes.")

Pour en revenir aux lignes d’import, on doit les ordonner ainsi :

Exemple :

import os  # import module de la lib standard
import sys # on groupe car même type 
 
from itertools import islice  # import du contenu du module
from collections on namedtuple # import groupe car même type
 
import requests # import lib tierce partie
import arrow # on groupe car même type
 
from django.conf import settings # tierce partie, contenu du module
from django.shortcuts import redirect # on groupe car même type
 
from mon_projet.mon_module import ma_bite # mon projet

Format du fichier

Indentation : 4 espaces. Pas de tab. C’est tout. Ce n’est pas du PEP8, c’est juste que les codes qui utilisent les tabs sont en (très très très très très très très très) grande minorité dans la communauté Python. Donc faites pas chier. Sinon on vous attend à la sortie de l’école. Tous.

Encoding : UTF8 ou ASCII (ce qui est de l’UTF8 de toute façon).

Docstrings

(c.f. PEP257)

On utilise toujours des triples quotes :

def fonction_avec_docstring_courte():
    """Résumé en une ligne."""
    pass

Si la docstring est longue (elle peut être très très très longue si vous le souhaitez) :

def fonction():
    """Résumé en une ligne suivi d'une line vide.
 
    Description longue de la fonction qui 
    se termine par une ligne vide puis une
    triple quotes sur sa propre ligne.
 
    """

Noms de variables

Lettres seules, en minuscule : pour les boucles et les indices.

Exemple :

for x in range(10):
    print(x)
 
i = get_index() + 12
print(ma_liste[i])

Lettres minuscules + underscores : pour les modules, variables, fonctions et méthodes.

une_variable = 10
 
def une_fonction():
    return locals() or {}
 
class UneClasse:
    def une_methode_comme_une_autre(self):
        return globals()

Lettres majuscules + underscores : pour les (pseudo) constantes.

MAX_SIZE = 100000  # à mettre après les imports

Camel case : nom de classe.

class CeciEstUneClasse:
    def methodiquement(self):
        pass

Si le nom contient un acronyme, on fait une entorse à la règle :

class HTMLParserCQFDDDTCCMB:
    def methodiquement(self):
        pass

On n’utilise PAS le mixedCase.

flattr this!

Afficher le queryset d’une requête dans les logs SQL sous Django

mercredi 25 décembre 2013 à 12:38

C’est Noël, 2 articles rien que pour vous dont un très interressant de Sam.

L’ORM de django pour les bases de données est chouette, agréable à utiliser mais construit des requêtes SQL qu’on ne peut reconnaître lors de l’analyse des logs MYSQL du premier coup d’oeil. Et quand on a des centaines de requêtes par secondes c’est carrément impossible de s’y retrouver.

Ce que je vous propose ici c’est d’afficher le queryset (sa ligne et le fichier qui le contient) qui a permit d’exêcuter la requête SQL que vous voyez défiler dans les logs SQL sous forme de commentaires SQL.

L’application se nomme Django Sql StackTrace. C’est facile à installer et ça peut sauver des heures de debug.

Installation Django Sql StackTrace:

Une bonne PIP comme toujours pour bien commencer.

pip install django-sql-stacktrace

Dans votre fichier settings de django.

INSTALLED_APPS = (
    .........................
    'sqlstacktrace',
    .........................
)
 
SQL_STACKTRACE = True

La variable SQL_STACKTRACE sert à activer le debug.
Pensez à le désactiver lorsque vous n’en avez pas besoin.

Où se trouve mes super infos de debug ?

D’après la doc vous pouvez executer un watch

watch -n1 mysqladmin -u login -pmot_de_passe processlist --verbose

Chez moi ça n’a rien donné. Mais du côté des logs MySQL la magie a opérée.
Vérifiez tout d’abord que vos logs sont activés dans mysql.

vi /etc/my.cnf
[mysqld]
......
log = /var/logs/mysql.log
......

Comment on teste ça ?

Redemarrez votre serveur web, surfez sur les pages de votre projet et observez les logs MySql. Vous deviez voir quelques chose de similaire:

tail -F /var/logs/mysql.log
		  644 Query	SELECT `auth_user`.`id`, `auth_user`.`password`, `auth_user`.`last_login`, `auth_user`.`is_superuser`, `auth_user`.`username`, `auth_user`.`first_name`, `auth_user`.`last_name`, `auth_user`.`email`, `auth_user`.`is_staff`, `auth_user`.`is_active`, `auth_user`.`date_joined` FROM `auth_user` WHERE `auth_user`.`id` = 65290
/* File "/Users/max/work/mon_projet/apps/mon_apps/views/others.py", line 146, in user_public_page
	user = User.objects.get(pk=user_id)
*/

Observez cette merveille !
Entre /* */ sont les infos générées par django-sql-stacktrace. J’ai nettoyé quelques fichiers pour plus de lisibilité.
Vous avez droit au chemin du fichier de la requête, à la ligne de la requête et à la requête django elle-même.

Une alternative ? J’ai pas envie d’installer d’app.

Pour les grosses feignasses ou si vous voulez juste tester occasionnellement quelques queries vous pouvez utiliser la méthode extra pour ajouter vos propres commentaires.

videos = Video.objects.filter(status='online').extra(where=['1=1 /* ceci apparaitra dans les logs mysql ! */'])

Cependant le WHERE 1=1 peut causer quelques baisses de performances, mais lorsqu’on est en debug en local ça peut servir !

PS: Je rappelle également le formidable outil django-debug-toolbar qui devient vite indispensable.

Alors ? Elle est pas belle la vie ?

flattr this!

Est-ce que “framework x” supporte la charge ?

mardi 24 décembre 2013 à 22:08

Oui.

flattr this!

Présentation de RapydScript

lundi 23 décembre 2013 à 09:12

Ceci est un post invité de ArtyProg posté sous licence creative common 3.0 unported.

Javascript est devenu le langage incontournable du Web. C’est un langage suprenant, avec lequel, entre des mains expertes, il est possible de réaliser des choses impressionnantes.
Néanmoins, pour des tas de raisons, il s’avère encore compliqué de créer et maintenir des projets d’envergure. De plus, de nombreux développeurs sont allergiques aux bizareries de Javascript.

Il existe depuis longtemps des solutions permettant d’éviter de programmer directement en Javascript.Le site http://altjs.org/ référence de nombreuses solutions dans ce sens.

Bien entendu, je me suis intéressé aux solutions ‘Python to Javascript’. Parmi ces projets, trois, selon moi, sortent du lot : Brython, Skulpt et RapydScript.
Le but de Brython et Skulpt et de s’affranchir totalement de Javascript.
Brython pousse le concept très loin, il permet d’utilier la balise <script lang=”python”></script> directement dans une page web. Il s’agit vraiment d’un formidable projet.

Si Brython et Skulpt sont si bien, pourquoi mettre en avant RapydScript ?
En fait, la particularité RapydScript est qu’il ne tente pas de s’affranchir de Javascript, bien au contraire. La syntaxe est ‘pratiquement’ celle de Python, mais il permet d’introduire du Javascript de façon totalement transparente.

Pour ceux qui ne sont pas dérangés par la langue de Shakespeare voici l’adresse du site officiel: https://bitbucket.org/pyjeon/rapydscript

J’ai mis en ligne un page contenant quelques applications réalisées avec RapydScript : http://salvatore.pythonanywhere.com/RapydScript

Voici encore un autre exemple, qui montre la facilité avec laquelle
on peut intégrer les librairies Javascript ici ‘canvas.js’:
http://salvatore.pythonanywhere.com/RapydBox (à voir avec Firefox ou Safari)

Le code Javascript produit est très lisible comme le montrent les exemples suivants:

def sumList(L):
    if len(L) == 0:
        return 0
    else:
        head, tail = L[0],L[1:]
        return head + sumList(tail)
 
def factorial(n):
    if n == 0:
        return 1
    return n * factorial(n-1)

Une fois compilé voici le code Javascsript produit:

function sumList(L) {
    var head, tail;
    if (len(L) == 0) {
        return 0;
    } else {
        _$rapyd$_Unpack = [L[0], L.slice(1)];
        head = _$rapyd$_Unpack[0];
        tail = _$rapyd$_Unpack[1];
        return head + sumList(tail);
    }
}
 
function factorial(n) {
    if (n == 0) {
        return 1;
    }
    return n * factorial(n - 1);
}

RapydScript n’est pas un gadget, on peut l’utiliser pour développer de
véritables projets.

Et pour terminer, vous pouvez utiliser node-webkit pour packager et diffuser vos programmes.

A vous de jouer…

flattr this!

5 choses à apprendre en priorité en Python

dimanche 22 décembre 2013 à 09:57

Quand on apprend un nouveau langage de programmation, on apprend d’abord les bases. Et pour la plupart des langages, elles sont communes : déclarer une variable, faire des conditions et des boucles, faire des fonctions, importer un code d’un autre fichier, etc.

Ce qui va différencier le moment où vous savez programmer dans CE langage, ce sont des notions qui lui sont spécifiques et que vous commencez à maitriser.

Voici 5 notions spécifiques au langage qu’il faut apprendre en priorité si vous voulez pouvoir dire “je code en Python” :

Pip

Pip est la moyen le plus utilisé d’installer une bibliothèque externe dans l’environnement Python. Dès qu’on veut faire un projet sérieux, on en a besoin. Tellement qu’il va en fait être inclus par défaut dans Python 3.4.

Lire l’article sur pip.

Virtualenv

Virtualenv permet d’isoler plusieurs installations de Python. A partir du moment où l’on travaille sur plusieurs projets en même temps, il devient vite indispensable. Mais personnelement, je l’utilise même quand je n’ai qu’un projet installé sur une machine car il me permet de le séparer du setup Python du système et d’utiliser des hooks.

Un outil qui a été ajouté dans la lib standard en Python 3.3. J’apprécie que le pragmatisme de l’évolution de Python qui intègre petit à petit les projets qui se sont révélés les outils de facto dans la communauté.

Lire l’article sur virtualenv.

Les listes en intention

J’ai envie de dire l’itération en générale, mais c’est un très vaste sujet, et il est couvert en grande partie par les 3 derniers points.

La liste en intention, ou liste en compréhension, est une manière de boucler sur un itérable (souvent une liste), avec optionellement un filtre, afin de produire une nouvelle liste. En une ligne.

C’est stylistiquement la marque de fabrique de Python (même si c’est piqué à Haskell). C’est également ce qui le rend aussi expressif. On peut presque coder tout un programme en déclaratif avec des enchainements de listes en intention.

C’est beau, propre, efficace et court. IN-DIS-PEN-SA-BLE.

Lire l’article sur les listes en intention.

L’unpacking

L’unpacking est une autre fonctionalité typiquement pythonienne qui permet de prendre un itérable (souvent un tuple), et de mettre ses éléments dans des variables d’une traite.

Cela permet d’augmenter drastiquement la lisibilité des programmes.

Lire les articles sur l’unpacking.

Les générateurs

Les générateurs permettent non seulement un énorme gain en performance, mais en plus ils autorisent le traitement itératif de flux de données dont on ne connait pas la taille en avance, voire de taille infinie. Si vous utilisez des expressions génératrices, vous pourrez le faire en déclaratif. Si vous utilisez yield, vous pourrez cacher un algorithme complet derrière une simple boucle for.

Lire l’article sur yield.

Le reste ?

Tout le reste, c’est du détail. Les décorateurs, la POO, l’opérateur with, les métaclasses, les astuces magiques pour faire ceci ou cela. C’est bien, mais ça peut attendre. Ce sont ces 5 notions, qui, bien utilisées, feront d’un programmeur un dev Python.

flattr this!