JulienPalard a écrit 14 commentaires

Ma version, inspirée des checksums IP qui calculent leur checksum en mettant leur checksum à zéro :

import sys
from pathlib import Path
from hashlib import sha1

def main():
    print("Hello world")


if __name__ == "__main__":
    file_hash = sha1("\n".join(Path(__file__).read_text(encoding="UTF-8").splitlines()[:-4]).encode("UTF-8")).hexdigest()
    if file_hash == "2747a01179b63b85af537c80c5f3ff88fdec3e62":
        exit(main())
    print(f"Corrupted file, script hash is: {file_hash}")
    exit(1)

Ici on expérimente avec Anki : tables de multiplications, régions, trucs appris lors d'une visite, … tout y passe.

J'aime beaucoup le côté « il ne t'embête pas avec ce que tu sais déjà ».

J'ai testé moi-même : j'ai appris les départements (nom, numéros, préfectures, emplacement), à coup d'une séance par jour (plus des révisions si je m'ennuie pendant les transports), ça marche juste. Bon au début ça m'a fait des séances de plus de 15mn (20 nouvelles informations à apprendre par jour par défaut), mais maintenant j'y passe moins de 3mn par jour (c'est de la révision pour éviter d'oublier).

Les plus : c'est packagé Debian (et oui ça marche sur téléphone avec Mobian, l'app est tout juste suffisamment responsive pour que ce soit tout à fait utilisable).

Les moins : le package Debian est un peu vieux, mais je ne m'en rends pas trop compte. J'ai juste voulu ouvrir une issue une fois mais le bug était corrigé depuis belle lurette…

J'ai deux projets sponsorisés chez Gandi, j’essaye donc de suivre ça de près.

Les informations que j’ai jusque-là sont très rassurantes, pas de panique.

un programme en Python consomme 30x plus d'énergie qu'un programme en Java

C'est seulement vrai si on oublie volontairement cython, numba, pythran, pypy, mypyc, …

Pierre Augier et al. ont fait un papier intéressant à ce sujet ici et ici.

Où on peut voir un même algorithme, implémenté en Python, tourner sur différents interpréteurs/jit/… et s'étaler très largement d'un ordre de grandeur plus performant que Java à un ordre de grandeur moins performant que Java.

TL;DR :

Our work shows that the performance of scientific programs depends less on languages than on the time spent on optimization and the developer skills to correctly use the right tools.

J'ai les images qui … 404 :

Par exemple :

https://img.linuxfr.org/img/68747470733a2f2f636c6f75642e616e7469706f756c2e66722f732f4a7471397878576371505764396d342f70726576696577/preview
☹

Je suis étonné de voir des sudo pip : je ne l'utilise jamais et le déconseille toujours : pour moi ça ressemble à un aimant à problèmes, ai-je raté quelque chose ?

Chez moi tout ce qui est hors de mon home c'est apt qui s'en occupe (seul, et donc sans problèmes), et pip se cantonne à des venv ou à ~/.local/ : pas de problèmes.

Il ne faut pas trop se plaindre, avant lorsqu’on appuyait sur Esc avec la sélection d’émoji ouverte, le commentaire qu’on rédigeait se fermait sans être sauvegardé : https://gitlab.com/gitlab-org/gitlab/-/issues/20262.

Mais oui, votez pour moi ♥

Pour avoir utilisé les deux (coverage -m pytest, tout simplement, et en utilisant pytest-cov), j'ai finalement eu moins de soucis avec coverage -m pytest, surtout avec des tests parallèles.

J'ai un exemple ici :

https://github.com/JulienPalard/oeis/blob/main/tox.ini

Où un tox -m all lance des tests sur 3 versions de Python en parallèle et agrège les résultat de coverage à la fin. Faire la même chose avec pytest-cov est un enfer ☹.

L'agrégation est particulièrement utile dès qu'on a quelque chose comme :

if sys.version_info > (3, 8):
    ...
else:
    ...

sans agréger à la fin, soit le if soit le else sera compté comme non couvert, alors qu'en agrégeant le if et le else peuvent être couverts (et atteindre le fameux 100%, ha, ha).

https://www.kline.sh/

Le souci de python3 -m venv .venv c'est qu'il crée un venv qui s'appelle .venv, donc le prompt ressemble à (.venv) mdk@seraph:/tmp.

Ça se personalise avec --prompt mais je trouve ça lourd python3 -m venv --prompt nom_du_projet .venv, on pourrait écrire python3 -m venv --prompt "$(basename "$PWD")", l'avantage c'est que ça traîne dans l'historique, mais je préfère encore m'en faire une fonction bash, comme ça je peux activer le venv en même temps :

venv () 
{ 
    deactivate 2> /dev/null;
    if ! [[ -d .venv ]]; then
        python$1 -m venv --prompt "$(basename "$PWD"))(py$(python$1 --version | cut -d' ' -f2)" .venv;
    fi;
    source .venv/bin/activate
}

Les petits $1 qui traînent c'est parce que j'ai plusieurs version de Python (3.4, 3.5, 3.6, 3.7, 3.8, 3.9, et 3.10 là), installés avec make altinstall donc je peux toucher le Python de ma Debian via python ou un Python compilé à la main via python3.x.

Demo time :

$ mkdir petitprojet
$ cd petitprojet/
$ venv
(petitprojet)(py3.9.4) $

ou

$ venv 3.6
(petitprojet)(py3.6.12) $

Pour ceux qui veulent comme moi plein plein de versions de Python, j'avoue aussi utiliser des fonctions bash pour ça. Elle est plus compliquée qu'elle pourrait : j'aime bien me compiler des beta, et j'aime bien avoir --with-pydebug mais uniquement après la 3.8, car avant la 3.8 le build de debug n'est pas compatible avec le build normal (pas pratique pour les extensions compilées).

compile_python () 
{ 
    local PY_VERSION="$1";
    local BETA="$2";
    local FLAGS="";
    if dpkg --compare-versions "$PY_VERSION" ge 3.8.0; then
        FLAGS="--with-pydebug";
    fi;
    local URL="https://www.python.org/ftp/python";
    ( cd /tmp;
    wget -qO- $URL/$PY_VERSION/Python-$PY_VERSION$BETA.tgz | tar -xzf - || ( echo "Version not found, check on $URL." );
    [ -d Python-$PY_VERSION$BETA ] && ( cd Python-$PY_VERSION$BETA;
    ./configure $FLAGS --prefix=$HOME/.local/ && make -j $(nproc) && make altinstall ) && rm -r Python-$PY_VERSION$BETA )
}

et tant qu'a faire :

compile_all_pythons()
{
    compile_python 3.5.10 &
    compile_python 3.6.12 &
    compile_python 3.7.10 &
    compile_python 3.8.10 &
    compile_python 3.9.5 &
    compile_python 3.10.0 b1 &
    wait
}

Côté exercices Python n'hésitez pas à squatter d'une manière ou d'une autre https://hackinscience.org.

(Je l'avais présenté ici : https://linuxfr.org/news/hackinscience-automatiser-l-enseignement-de-python)

L'approche de correction est en fait celui des « tests » donc : vérification de sorties attendues pour des entrées données.

Oui complètement, ça ressemble parfois comme deux gouttes d'eau à des tests unitaires. Sauf qu'au lieu de sortir un AssertionError j'essaye de rédiger un message qui explique pourquoi c'est faux, de manière à ce qu'un utilisateur ne soit jamais bloqué (utopique peut être).

Si j'ai bien compris la fin de la présentation, il faut un bot pour la correction automatique de l'exercice mai je n'ai pas bien compris s'il en faut un différent par exercice ou s'ils utilisent tous le même.

J'écris un "correcteur" par exercice. Pour 72 exercices ça fait 5049 lignes de Python, soit en moyenne 70 lignes par "correcteur" (avec bien sur un peu de redondance : les imports toujours pareil, le setup de gettext, le main …). Je trouve ça plus propre et maintenable comme ça : quand je veux améliorer la correction de tel ou tel exercice, je sais rapidement où c'est (le script fetch.py me crée un dossier par exercice avec dedans : wording-fr.md, wording-en.md le texte présenté à droite, check.py le code de correction, …

D'après le gabarit de code posté, ce bot prend la saisie effectuée par l'élève et s'attend à ce que ça ne renvoie pas d'erreur en l'exécutant. Du coup, on peut mettre n'importe quel code Python pourvu que ça ne fasse pas d'erreur ?

Chaque "code de correction" prend l'approche qu'il veut, parfois j'exécute le code de l'élève avec subprocess.run(), parfois une seule fois, parfois plusieurs fois si je veux tester plusieurs paramètres. Sinon j'importe les fonctions de l'élève et je les exécute avec différents paramètres pour vérifier leur résultats. Dans le code d'exemple que j'ai mis, qui teste la bonne implémentation d'une fonction bencode par l'élève :

• J'itére d'abord sur une collection de "messages à tester"
• J'utilise ma fonction "de référence" bencode, pour encoder le message de test
• J'exécute la fonction bencode de l'étudiant
• Si nos deux résultats divergent, je lui forge une erreur. La fonction fail est celle qui print l'erreur, l'exercice sera donc considéré faux.

Dans tous les cas si quelqu'un rend une fonction de trop, innutilisée, mais que son programme fonctionne, je ne pourrai pas m'en rendre compte. Par contre s'il se met à print en trop, ça risque de déplaire au bot.

Exact, j'utilise firejail (comme ça) pour exécuter le code des étudiants avec le moins de droits possible, même pas d'accès internet. J'imagine qu'avec du talent on doit pouvoir trouver des choses à faire, mais pour le moment (et j'en suis étonné) je n'ai vu personne tenter de contourner la sandbox.