Thomas Hervé a écrit 139 commentaires

Rien que ça.

Je parle d'une importance en taille, bien qu'il n'y ait pas que la taille qui compte. Si tu veux des chiffres: Ubuntu Install Party à Paris: 4000 personnes. Peut-être que d'autres événements sont aussi garnis, mais j'en doute.

Je ne dit pas que la diffusion fait d'Ubuntu la meilleure des distributions. Je dis juste que si Mark S. était incompétent, la communauté ne serait pas si importante. Ce qui ne veut pas dire qu'il ne commet pas des erreurs, loin de là.

Pour revenir à ta comparaison, ça serait comme dire que Bill Gates est un mauvais commercial...

Ubuntu est dirigé par un clown mégalomane et incompétent dans la gestion d'une distribution communautaire.

Ahah, j'ai bien ri. On a l'habitude de tes diatribes aigries dès qu'Ubuntu est mentionné, mais là tu fais fort.

Si il était si incompétent, la communauté Ubuntu ne serait pas la plus importante des communautés de distributions.

Quand au côté mégalomane, viens à l'install party à la Villette le mois prochain, il devrait être là. Tu pourra discuter avec lui ça remettra les choses en perspective.

Matt Zimmerman est directeur technique (CTO) chez Canonical, et responsable du programme Ubuntu, pas CEO.

quand la route t'impose de choisir de passer à gauche ou à droite d'un étang quelconque, tu fonces tout droit en gueulant "rien à foutre !" ?

Ca c'est de la métaphore... J'ai du mal à voir le rapport.

les distributions fourniront python 3.0 et python 2.6 - comme elles se trainent déjà un lourd passif de python 2.2 python 2.3 python 2.4 python 2.5 : je ne vois pas le problème pour des utilisateurs normaux (non-codeurs)

maintenant pour tes utilisateurs-en-fait-codeurs tu crains qu'ils aient deux fois plus de boulot à faire, deux versions incompatibles à se trainer, s'ils décident de viser en même temps les branches 2 et 3 de python ?

bah oui. maintenant tu es parfaitement libre d'ignorer l'une des deux branches ou de demander de l'aide, hein. ça se fait.

Un projet opensource demande déjà beaucoup d'effort en temps normal pour essayer de minimiser les gros travaux de ce type. De l'aide, un projet en a toujours besoin, même sans une migration aussi importante.

Pour en revenir à ce que tu dis, les utilisateurs seront forcément impacté, car les bibliothèques n'existeront pas pour Python 3.0. Le travail des distributions, qui se limitait dans beaucoup de cas à recompiler la même version de la bibliothèque pour plusieurs version de Python, sera lui aussi doublée: besoin de compiler 2 versions différents des projets.

Comme je l'ai déjà expliqué ça et là, les changements brisant la compatibilité est d'éviter les erreurs de programmation.

Je ne conteste pas les changements en soi. La plupart me semble sensé (sauf les ABC peut-être, mais bon...). Mais il faut offrir un moyen aux utilisateurs de faire tourner leur code sur 2.x et sur 3.0, avec des future import par exemple.

Pour l'instant rien n'est foutu, mais il y a un gros enjeu pour 2.6 d'offrir une migration aisée.

Pour les modules écrits entièrement en Python, l'outil 2to3 s'occupe de convertir automatiquement tout le code. Il n'y a rien à faire.

Ca, c'est une belle illusion. 2to3 arrivera peut-être à convertir des projets simples, mais a peu de chances de convertir un projet plus complexe. J'attend de voir ce que ca peut donner sur SQLalchemy ou Genshi par example.

C'est contraire à ce qui a été fait jusqu'à présent. Tu parle de Python 2.0: un programe écrit pour Python 1.5 tourne très bien sur Python 2.0. Là il y a de fortes chances qu'un programme écrit pour Python 2.5 ne puisse même pas se lancer sur 3.0.

Python 3.0 est un bon objectif. Cependant il faut mettre en garde les gens de ne pas s'en servir pour écrire de vrais programmes, et attendre justement les transitions offerts par les version 2.6 et suivantes.

Heureusement que tout le monde ne casse pas tout pour retirer les vieux bugs.

Comme je le dis dans le commentaire, Python a toujours su utiliser les DeprecationWarning pour prévoir une migration de ces utilisateurs. Et je cherche encore un point dans Python 3.0 qui ne pouvait pas passer par cette case.

Apparemment l'enthousiasme est de mise, mais j'ai du mal à ne pas voir tous les problèmes de cette version. Voir le point de Glyph Lefkowitz que je partage en grande partie: http://glyf.livejournal.com/72036.html.

Pour moi, cette version ne devrait même pas avoir de version officielle. Une des forces de Python est sa stabilité, et son évolution pas à pas. Casser toute la compatibilité d'un coup n'a aucun sens. Rien dans les nouvelles fonctionnalités ne nécessitaient de ne pas passer par la case habituelle "PendingDeprecation/Depreaction/Deletion". La preuve? Beaucoup de ces nouvelles fonctionnalités vont être portées dans Python 2.6.

En tout cas, cette version s'annonce comme un mal de tête énorme pour tous les créateurs de bibliothèques, qui devront pendant une période de temps importante (python 2.3 est encore utilisé énormément, voir 2.2) fournir 2 versions de leur code... Quand on voit le mal que les core développeurs ont à porter les bibliothèques internes (cf email), il y a de quoi s'inquiéter.

Bref, un bel objectif, mais incompatible avec une véritable utilisation selon moi.

Tu remarqueras que j'ai mis en doute la propre crédibilité de ma comparaison :).

Par contre, je n'ai jamais connu de musiciens qui commencaient un album en citant leur marque d'instrument.

Et toi tu sembles confondre l'expérience informatique avec l'expérience sous Windows :). Il me semble que les Norton Utilities n'ont jamais existés que sous DOS/Windows, donc effectivement j'en ai une expérience limitée. En plus ce sont des logiciels payants qui ne sont pas fournis quand tu achètes ton PC hors marque/grande surface.

Mais tu dois avoir raison, les outils Norton dont j'ai fait la malheureuse rencontre doivent être Norton Systemworks, avec l'antivirus, le firewall etc.

Et mes poils ont le temps de voir le monde, merci pour eux.

L'informatique est un outil seulement pour certain.

Oui, justement, il ne devrait pas avoir à mettre un logiciel dans dans les remerciements. Ca devrait 'juste marcher'. Il ne devrait pas avoir à récupérer ses données car il ne devrait pas les perdre. Son système devrait être assez stable pour qu'il n'aie pas besoin "d'utilities" pour fonctionner.

Il est difficile de trouver un parallèle intelligent, mais imagine un peintre qui remercie la fabricant de pinceaux, un musicien qui remercie un fabricant de micros. Je ne crois pas avoir vu ça :).

Ca fait de bien longues années que je n'en ai pas eu besoin,

Je crois que c'est pour ça :). J'ai eu l'occasion de manipuler la version 2005 (ou 2006) sur un PC acheté par mon père, et c'est une horreur. Ca bouffe la moitié des ressources de la machine, ca sort plein de logs horrible à l'utilisateur, l'interface est horrible. J'ai mis 1 bonne heure à ouvrir un port pour une application, et au rédémarrage suivant il avait tout remis à 0.

Pour moi ces softs sont des verrues immondes sur la merde qu'est Windows pour faire des choses qui devrait être fait de base.

--
Thomas

Un truc comme ca doit fonctionner:

def main():
    f = file("myfile", "r+b", 0)
    i = f.readline()
    while i:
        c = i.find("bar")
        if c != -1:
            a = f.tell()
            f.seek(-len(i) + c, 1)
            f.write("foo")
            f.seek(a)
        i = f.readline()
    f.close()

En gros tu te balades dans ton fichiers, quand tu trouves ton texte ("bar") tu te replace à la bonne position et tu écris ton nouveau texte ("foo"). Le problème avec la gestion des fichiers (enfin de ce que je sais sous Linux), c'est que tu ne peux pas insérer de données. Tu peux remplacer 3 caractères par 3 caractères, mais tu ne peux pas déplacer toutes les données du fichier pour mettre plus de données (insérer une ligne par example).

SI tu programmes en style objet un peu extrême, le corps de ton appli consiste principalement en une suite de déclaration d'objets interdépendants, qui gèrent après leurs interactions entre eux, donc par conséquent, une bonne partie du code est localisé au niveau des constructeurs... et des destructeurs, encore faut-il qu'il y en ait.

Le parallèle entre les constructeurs et les destructeurs est complétement mal venu. Le constructeur d'un objet est appelé à l'initiative de l'application, alors qu'en général on ne peut pas prévoir quand l'appel à un destructeur sera fait. Avoir une logique applicative dans un destructeur c'est un très mauvais design objet, il faut mieux avoir une méthode de finalisation appelée explicitement.

Tu parles en particulier de Python, alors qu'en Python l'utilisation des destructeurs est très découragée. D'abord parce que cela casse une partie du GC (en gros il a beaucoup de mal a détecter les cycles lorsque les objets définissent une méthode __del__). Ensuite parce qu'il y a (très) souvent moyen de faire mieux et plus propre. Un destructeur doit être utilisé dans des cas très particuliers.

Et je rajoute encore 2 wikis assez récents :
- Le Python Tutorial Wiki http://pytut.infogami.com/
- Et le Python Reference Wiki http://pyref.infogami.com/

Cela reprend les pages de docs.python.org mais sous la forme d'un wiki, et on commence à faire apparaître des exemples et des commentaires intéressants.

--
Thomas

Non il n'est pas pilotable à la souris, mais au clavier. La navigation doit pouvoir se faire à la souris (et donc être implémentée assez facilement), mais un certain nombre de contrôles nécessitent un peu plus de boutons, comme le volume par exemple.

Après c'est compatible LIRC apparemment, donc tu dois pouvoir faire pas mal de choses en passant par ca.

Non pour moi c'est du sucre syntaxique quand même :). Quand tu utilises un lock, tu sais que tout code l'utilisant doit être dans un try/finally. Donc :

lock = threading.Lock()
with lock:
    # Critical section of code

est tout à fait équivalent à

lock = threading.Lock()
try:
    # Critical section of code
finally:
    lock.release()

Le dernier est explicite, alors que with contient un fonctionnement implicite. Tout est une question d'habitude après, mais ce n'est pas une révolution en tout cas.

Il y a aussi une utilisation intéressante avec les threads, présentée ici: http://docs.python.org/dev/whatsnew/pep-343.html :

lock = threading.Lock()
with lock:
    # Critical section of code

De plus, c'est personnalisable, on peut imaginer pas mal de choses, comme des transactions au niveau du code. Mais ce n'est que du 'sucre syntaxique', donc rien que l'on ne pouvait faire avant (avec plus de code il est vrai).

D'abord bravo pour ton journal, j'espère que tu proposera une dépêche d'aussi bonne qualité pour la sortie finale :).

Quelques commentaires:

> Ajout des expressions conditionnelles

Cette syntaxe m'horripile, j'espère que cela restera dans les scripts simples et qu'on ne verra pas ca dans des bibliothèques. La lisibilité est très douteuse je trouve.

> yield est maintenant une expression qui retourne une valeur

C'est une nouvelle plus importante qu'elle ne paraît :). Cela permet de communiquer entre un générateur et la fonction appelante, et donc de créer un pseudo système de coroutine (ce n'est pas exactement cela non plus je trouve).

> Ajout du mot clef "with" qui est TRES pratique

Mouais, pareil que plus haut, je trouve ca intéressant pour un petit script, mais le côté magique qui se cache derrière me rebute un peu.

> ElementTree est livré de base :
>http://docs.python.org/dev/whatsnew/modules.html#SECTION0001(...)
> et ça c'est une très bonne nouvelle (c'est sur lui que se base lxml
> par exemple)

Oui c'est très bon ElementTree, mangez-en! Il définit une nouvelle API propre à Python qui est très intuitive et performante. Refaire du DOM après est un calvaire. Note par contre que lxml n'est pas basé sur etree, il adopte juste cette API.

> Et pour finir, quelque chose de magnifique : sqlite3 est fourni en
> standard avec Python !!

Oui, c'est très intéressant, c'est un choix que php5 avait déjà fait. Par contre il faut toujours avoir sqlite3 d'installé auparavant.


--
Thomas

> Ajax avec Ruby on Rails (ouais, je sais, je fais à fond dans le hype, là).

RoR c'est dépassé déjà, tout le monde utilise django maintenant: http://www.djangoproject.com/

--
Thomas

> A propos de jeux vidéos, c'est aussi pour ça que 99% des jeux vidéos > sont écris en C et/ou en C++

Avec des raisonnements comme ca tu vas loin: 90% des postes de bureau sont sous windows, 90% des logiciels bureautiques sont ceux de Microsoft. J'espère que tu conviendras que ca n'en fait pas les meilleurs produits :).

Aujourd'hui C/C++ est le langage le plus utilisé (en opensource) parce que c'est aussi le plus connu (et qu'en codant proprement tu arrives surement à quelque chose d'assez performant). Mais avec l'augmentation des fonctionnalités (je pense par exemple à un environnement de bureau), il est intéressant de faire une application dans un langage plus haut niveau (python/ruby par exemple) pour se concentrer vraiment sur les fonctionnalités et arrêter de se prendre la tête avec des segfaults.

Au niveau des applications réseau, on voit aussi pas mal d'applications écrites dans un langage plus 'évolué': bitorrent en python, mldonkey en ocaml, ejabberd en erlang, twisted en python (flumotion, buildbot).

Bref, ya de la place pour tout le monde, la seule chose qui compte c'est que celà fonctionne.

--
Thomas

Comme tout le monde, j'ai créé mon framework car tous les autres sont mauvais !

Trève de plaisanterie, j'ai utilisé mod_python pendant un temps et j'en étais assez satisfait. Mais c'est un peu trop bas niveau pour être utiliser au quotidien, et je ne considère pas ca comme un framework web.

Twisted est classé dans ce questionnaire, mais il pêche plutôt dans le domaine du web. Le futur avec l'extension web2 paraît plus prometteur.

J'utilise pour l'instant Nevow, qui offre pas mal de choses intéressantes (pour les personnes qui utilisent Twisted...). Mais bon ca fait plus d'un an que c'est en refactoring, donc une version stable serait la bienvenue. La gestion des templates XML est bien mais devient vite compliquée. Stan (écriture d'XML en Python) permet lui de faire des pages quick&dirty, mais on mélange trop logique et présentation pour que ce soit maintenable au long terme.

Quant à Trac, je ne pourrais plus m'en passer, c'est vraiment un outil génial.

Pour le plaisir, un post avec tout plein de choses intelligentes :

http://glyf.livejournal.com/51057.html

QOTW : "J2EE is the Big Mac here"