Astuces et sites Web Python
Vidéo sur les expressions régulières en Python : liste Youtube de 15+ videos, de débutant jusqu’à niveau avancé (regardez la playlist sur la droite pour voir les 15) !
Vidéo sur les expressions régulières en Python : liste Youtube de 15+ videos, de débutant jusqu’à niveau avancé (regardez la playlist sur la droite pour voir les 15) !
Cette astuce vient de Dan Bader. Du code, rapidement :
# Émuler ce que fait la std lib :
>>> import datetime
>>> aujourdhui = datetime.date.today()
# Le résultat de __str__ doit être lisible = comme une chaîne :
>>> str(today)
'2017-02-02'
# Le résultat de __repr__ doit lever les ambiguïtés possibles :
>>> repr(today)
'datetime.date(2017, 2, 2)'
# L'interpréteur Python en ligne de commande
# utilise __repr__ pour inspecter les objets :
>>> today
datetime.date(2017, 2, 2)
Le code est simple, il fautt avoir paplay
d’installé (je ne sais pas si c’est installé par défaut dans Debian).
A partir de là voici un exemple de code qui joue un fichier ogg
:
# python3
>>> import subprocess
>>> subprocess.Popen([
... "paplay",
... "/home/olivier/.local/blah/Mission_Failed.ogg"
... ]).poll()
>>>
source
)source
, cloner la librairie à laquelle on veut contribuer viagit clone [repo concerné]
pip
(ex : pip_env_lib
)pip_env_lib
, installer l’environnement pip via pipenv install
pip_env_lib
, lancer le « shell pip » via pip shell
source
pip install -e .
pip install -e .
(n’oubliez pas le .
qui change tout, cela indique le répertoire à utiliser) signifie « si jamais le shell Python en cours essaie d’accéder à la librairie à laquelle on veut contribuer, aller la chercher dans source
». En fait, concrètement parlant, pip
fait simplement un lien symbolique entre le dossier source d’installation de pip
(ici c’est pip_env_lib
), et le dossier source
. N’oubliez pas que cela ne concerne le shell Python en cours (ici pip_env_lib
).
L’avantage pratique de ce « lien symbolique », c’est qu’il est directement relié au code source. Donc, lorsqu’on modifie le code source de la librairie elle-même (dossier source
), elle est immédiatement disponible. Si on fait donc des fichiers de tests unitaires, il suffit de les relancer, les modifications du code source sont toujours instantanément prises en compte. Toujours dans le shell Python en cours (ici pip_env_lib
).
mkdir [source]
cd [source]
git clone [repo concerné]
cd ..
mkdir [pip_env]
cd [pip_env]
pipenv --python 3 install
pip shell
pip install -e .
.. et les modifications dans [source]
peuvent commencer !
La documentation détaillée en anglais se trouve ici.
Bien meilleure que ce qui suit, mais longue, longue…
Voici les notes prises à la volées, d’un contributeur plutôt habitué à faire des contributions dans le monde Python.
Toute nouvelle note / correction éventuelle est la bienvenue.
Il y a trois choses différentes qu’on a tendance à confondre, mais qui n’ont fondamentalement aucun rapport. On a tendance à les confondre parce qu’on essaie d’utiliser, pour des raisons pratiques, le même nom, mais dans trois cadres différents.
Ces trois choses à bien dissocier sont :
– le nom du package PyPI : dans le fichier de déploiement setup.py
, il est défini dans le paramètre « name
» de la commande setup()
. C’est ce qui est vu dans PyPI
.
– le nom du projet qu’on met dans github : c’est le répertoire qui contient tous les fichiers du projet (= il peut être totalement différent, en général on s’arrange pour les appeler d’un nom différent) = c’est ce qu’on clone dans l’ordre git clone [repo concerné]
– le développeur final qui fait un « import
» dans son code : ce module là peut être aussi différent, car c’est du Python. En général, c’est le répertoire de premier niveau du package (il doit contenir, bien sûr, « __init__.py
» pour être vu comme un package et importable par Python). En général : « from [ma lib] import [quelque chose]
« .
En général, on essaie de s’arranger pour que le nom du package sur PyPI
soit le même que le nom du package dans le code Python même.
Mais s’il est déjà pris (dans un des trois contextes), il faut forcément utiliser un autre nom, et c’est là qu’il faut faire attention à ne pas se mélanger les pinceaux.
Pour faire un nouveau package sur PyPI
le plus homogène possible :
PyPI
: si ça fonctionne, alors vous pouvez continuer. Sinon, il faut utiliser un autre nomDans PyPI
, les versions sont obligatoirement du type «a.b.c
».
En général :
[a].[b].[c]
[a] = fonctionnalités totalement nouvelles / incompatibilité
[b] = améliorations / nouvelles "petites" fonctionnalités
[c] = correctifs bogues
Lorsque vous faites une nouvelle contribution, vous devez obligatoirement fournir un fichier setup.py
.
Dans ce fichier, setup.py
, il y a une fonction, ici aussi, obligatoire : setup()
.
Cette fonction, parmi tous les paramètres, a un paramètre particulier : classifiers
qui permet au niveau de PyPI
de dire « ce package est rangé dans telle(s) catégorie(s) ». La liste des expressions disponibles se trouve ici.
On peut chercher partout sur le Web, ça part toujours un peu dans tous les sens et beaucoup ont des solutions différentes.
C’est un peu comme les outils pour gérer le travail en équipe… ou la mise en production de Django : plein de solutions, et aucun n’est officiellement supportée.
Eh bien maintenant, c’est un petit pas pour Python, un grand pour les développeurs !
Il existe maintenant des guides de packaging sur python.org.