Nouveau modèle de fichier Python 9
Il fallait bien s’y mettre un jour. Dans un an Python 3 sera probablement assez mûr et répendu pour envisager une switch. Du coup j’ai changé mon modèle de fichier Python vide, il ressemble maintenant à ceci.
Il fallait bien s’y mettre un jour. Dans un an Python 3 sera probablement assez mûr et répendu pour envisager une switch. Du coup j’ai changé mon modèle de fichier Python vide, il ressemble maintenant à ceci.
Je préfère Woody à Bill.
A un moment vous allez devoir proposer à vos utilisateurs de télécharger un fichier. Mais Django n’est pas du tout fait pour streamer des données, et du coup lui laisser cette tâche est un gros gouffre à performance qui va bloquer un de vos workers pendant tout le transfert.
Seulement parfois, il faut quand même générer le fichier via Django, ou au moins checker des permissions, bref, faire un traitement quelconque du côté du code Python. Comment faire alors ?
Faut virer les smiley des logiciels de chat. Utilisons des caractères UTF8, ça sera plus léger, et plus interropérable.
Oui
Les Class Bbased Views se trouvent maintenant partout en Django. Je les comprends maintenant très bien, et les utilise souvent au mieux. Dernièrement j’ai du utiliser django-rest-framework, une très belle application, qui fait un usage utile et massif des CBV, et effectivement, cette architecture m’a rendu très productif.
Mais je maintiens ce que je dis depuis le début : ce n’est pas un pas en avant.
J’ai bricolé une config pour iPython dernièrement. Rappelez-vous, on peut complètement customiser ce shell.
Voici ce que j’ai dans mon ./.config/ipython/profile_default/ipython_config.py…
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 pour obtenir un effet, alors l’objet est un callable.
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.
jQuery est très bien foutu, non content de permettre d’utiliser des libs concurrentes utilisant la même API avec noConflict()
(c’est beau l’open source quand même), elle permet également d’utiliser en même temps une version plus récente ou plus ancienne de son code, facilitant les migrations.