The Fool moon

Quiconque qui ait un jour touché aux CSS est convaincu de l'intérêt d'avoir une mise en page indépendante du contenu, voir différentes mises en pages selon le client accédant à la page... et est aussi convaincu de combien le langage des CSS est une plaie. Peu de factorisation de code possible (combien de copier-coller pour des codes abscons en hexadécimal), et donc des fichiers illisibles, où la construction générale de la mise en page est perdue dans les détails techniques à rallonge.

C'est là qu'arrive Sass, qui propose une sorte de préprocesseur, qui offre un langage évolué (avec même deux grammaires possibles de ce langage) qui est ensuite compilé en CSS traditionnelles. Il suffit d'aller sur le site web de Sass, les exemples de code parlent d'eux mêmes. L'implémentation officielle, en ruby, est disponible dans Debian (prendre le paquet de unstable pour avoir la nouvelle syntaxe scss), et il existe aussi une implémentation en perl (mais je ne sais pas si elle gère scss). Le compilateur propose même un mode où il monitore les changements sur le fichier source, qu'il recompile dès que nécessaire : c'est très agréable au codage.

Et, cerise sur la cerise, la syntaxe sass est disponible dans le colorateur syntaxique Pygments, et pour il existe un patch pour scss, ce qui permet d'avoir la coloration syntaxique dans Bristoledit (rassurez-vous, c'est aussi possible dans vi et emacs).

Après ça, on ne peut plus refaire des CSS old-school sans souffrir...

Je viens d'installer webbzr sur TheFool, une interface web qui permet d'afficher élégament et simplement le contenu des dépôts bazaar publics.

Certes, webbzr est en php, mais il est léger et simple à installer, alors que demander d'autres ? Après tout, simple is beautiful.

J'avais certes déjà une plateforme Trac d'installée, mais tous les dépôts n'ont pas besoin d'autant.

On y trouvera notamment :

• le dépôt de RstWiki, le moteur de wiki minimaliste qui fait tourner mes pages perso (et qui pour le coup mériterait peut-être un Trac...) ;
• mes fichiers de configuration, tellement c'est pratique de les récupérer sur n'importe quelle machine qu'ils sont versionnés, et tellement c'est pratique de lire ceux des autres que je partage les miens.

Un de mes objectifs pour la prochaine version de Bristoledit est de pouvoir faire fonctionner l'éditeur aussi bien avec Python 2 que Python 3, voir même avec Pypy. Pourquoi ? Parce que Python 3, c'est l'avenir, le language est plus propre, plus agréable. Mais Python 2 reste encore très utilisé, et certaines bibliothèques (PyGTK) ne sont pas encore compatibles avec la version 3. Et Pypy, parce qu'avoir un interpréteur plus rapide que CPython, c'est la classe.

La manière traditionnelle pour avoir du code compatible entre Python 2 et Python 3 consiste à l'écrire en Python 2, puis à le convertir avec 2to3. Mais c'est tout de même relativement contraignant.

Aussi, je me suis dit que j'allais essayer d'avoir un code fonctionnel avec ces trois interpréteurs, sans traduction préalable, comme l'a fait Ryan Kelly pour PyEnchant.

Voici donc upy (pour universal python), un module qui permet de s'approcher de la sémantique de Python 3, mais avec du code fonctionnel quelque soit l'interpréteur.

Exemples :

from upy import *    # oui, normalement ça ne se fait pas. Ici, on écrase sans

                     # discuter les fonctions internes de Python 2 par des

                     # équivalents de Python 3



spam = str()         # hop, une chaîne *unicode* vide

eggs = bytes()       # hop, un tableau d'octets (attention cependant, la

                     # sémantique de eggs[i] n'est pas la même entre Python 2

                     # et Python 3



spamspam = u('Hêllo Wôrld')    # u("") remplace u"", qui n'est valide qu'en

                               # Python 2

eggseggs = b("que d'octets !") # de même, b("") remplace le b"" de Python 3



uprint(spamspam)     # le print de Python 2 ne se remplace pas facilement...

                     # uprint a la même sémantique que le print de Python 3

                     # il est possible d'importer du __future__ le print de

                     # Python 3 dans Python 2.6, mais on perd alors la

                     # compatibilité avec Python 2.5 et Pypy.

D'autres objets sont disponibles, voir la documentation du module. Il est aussi possible de ne pas écraser les versions originelles, et d'utiliser juste des ustr, ubytes, etc.

Maintenant, il n'y a plus qu'à réécrire Bristoledit pour profiter de tout ça !