Victor STINNER a écrit 1632 commentaires

Je trouve ça affligeant de s'émerveiller devant la correction d'un "bug" aussi vieux Netscape 1.0 (allez, Phoenix 0.1 :-)). Quand j'ai migré de Gnome à KDE, j'étais très heureux d'avoir un navigateur web intégré au bureau :
* boutons KDE
* barre de défilement KDE
* dialogue du choix de fichier KDE
* correcteur orthographique et recherche dans les "textarea"
* etc.

Visuellement, Konqueror s'intègre très bien dans KDE.
http://www.haypocalc.com/tmp/konqueror.png

Je serai très heureux pour les utilisateurs de Gnome que KHTML puisse utilise Gtk (projet en développement...).

Grâce au SVG, Firefox bouffe 100% du CPU quand on déplace la souris au dessus cette carte de suisse. Donc pour répondre à la question : « OUI, Firefox est enfin au niveau de Flash ».

En pendant ce temps, la dernière Ubuntu propose d'installer Gnash...

Bonjour, comme tous les sujets abordés dans ce journal et ses nombreux commentaires m'intéressent, j'ai rédigé un billet dans mon blog pour réunir toutes les informations que j'ai pu trouver.
http://www.haypocalc.com/blog/index.php/2007/10/16/79-revers(...)

Rouvrir un journal serait peut-être plus intéressant, mais je n'ai pas envie de traduire la syntaxe Dotclear en syntaxe linuxfr...

Mais non, il existe Mono qui est libre et dispo pour de nombreuses architectures et OS.

Dommage de ne pas être migré vers COBOL.NET plutôt que Java. Il faudrait voir un peu plus sur le long terme, dotNET a un avenir tout tracé (supporté par Microsoft, marque de confiance) alors que Java est tombé dans le côté obscur de la force (contaminé par le virus GPL). Java petit à petit va éclater en multiple versions incompatibles entre elles, alors que dotNET est certifié Microsoft, preuve que le programme va fonctionner sans problème.

Utilise un proxy... mais il faut que le proxy ne soit pas bloqué :-) Bon ou alors regarde ça chez toi, dans un cybercafé ou chez un ami.

Dans l'idéal un snippet réalisé par un allemand devrait être accessible au français et réciproquement.

Non, j'ai dit le contraire : j'aimerai que ça soit impossible :-) Quand on cliquerait sur le drapeau « Deutsch », les snippets francophones disparaitraient et seuls ceux en allemand seraient visible. Je pars du postulat qu'il faut savoir lire l'allemand pour comprendre un code écrit en allemand. Et dit encore d'une autre manière : un pur francophone ne sera que pollué par les codes écrits dans une langue étrangère.

Comme le dit crétin.fr : « Téléphoner à l'étranger ça sert à rien, parce qu'à l'étranger ils parlent l'étranger ».

Voilà, je pense que mon argumentation est irréfutable ;-)

P.S. : S'inspirer de Wikipédia avec les liens interwikis ;-)

Ah c'est pour ça que c'est tellement lent, pff. En plus, le bleu est moche et le rouge aussi.

ICAP est un protocole utilisé par les logiciels de cache web (essentiellement HTTP et SMTP). Exemple de logiciel qui l'utilise : Trend InterScan (anti-virus). Lire ICAP pour les détails.

C'est une très bonne nouvelle que Squid le supporte. Apparemment, ça fait pas mal de temps qu'ils bossent sur le support d'ICAP.

« le melange francais/anglais n'aide pas non plus (dans les tags, dans le descriptif) »

J'ai posté quelques bouts de code pour tester, et c'est vrai que la mélange des langues (français et anglais) est troublante. Il faudrait pouvoir indiquer la langue du code et que ça soit le 1er critère de sélection. Comprendre que (par exemple) l'affichage des tags sur la page d'accueil dépendrait de la langue choisie. À la limite, il faudrait permettre de soumettre des tags dans sa langue maternelle + en anglais... mais avoir plusieurs versions, ça devient compliqué pour l'utilisateur.

Sinon, j'ai vu le tag "fuzzer" mais quand j'ai cliqué, y'avait aucun code associé :-( Je supose que c'est un code privé. Si c'est le cas, il faudrait ignorer ses tags dans l'affichage des tags...

Plus un ordinateur va vite, plus les langages de programmations peuvent gagner en abstractions. Les premiers ordinateurs étaient programmés en langage machine et on était limité aux spécficiations de la machine.

Si on observe l'évolution du langage Python, on peut voir les objets de haut niveau naître petit à petit. Python 2 permet de manipuler des caractères plutôt que des octets ('unicode' vs 'str') et Python 2.4 permet enfin d'avoir des nombres entiers sans limite débile (et source de nombreux bugs) à quelques milliards ('long' vs 'int'). D'ailleurs, Python 3000 va utiliser les types de haut niveau par défaut : "abc" désigne un chaîne de vrais caractères (et non pas d'octets comme en C) et les types int & long fusionnent.

C'est pas spécifique à Python, la programmation orientée objet est plus lente qu'un programme cablé en dur (du C par exemple), mais aujourd'hui on peut se permettre des perdre quelques pourcents de CPU et de mémoire à l'exécution pour accélérer le temps de développement.

À mon avis, les langages de programmations doivent monter en abstraction. Le but ultime étant d'écrire un programme dans sa langue maternelle... comme ce qui est présenté dans ce journal... sauf que je doute que ce jeu pacman soit jouable (c'est pas encore au point) ;-)

La solution plus carré mais plus lourde à mettre en place est le parefeu NuFW :-)

Quand la table des connexions grossit, conntrackd va prendre jusqu'à 50% de CPU. Pablo travaille sur ce point noir, et il sera sûrement résolu à court terme.

Autoconf offre différentes macros pour tester la présencer d'une bibliothèque, fonction, symbole, etc. Par contre, le comportement en cas de succès ou d'échec est libre. C'est au programmeur de choisir l'action réalisée, souvent un appel à AC_ERROR() qui va afficher un message et tout arrêter. En stockant le résultat de chaque test, on peut appeler AC_ERROR() tout à la fin. C'est ce que fait un bon configure.ac. Par contre, je sais pas s'il existe des méthodes propres pour le faire. Exemple de configure.ac utilisant des bidouilles pour arriver à ses fins :
http://software.inl.fr/trac/trac.cgi/browser/mirror/edenwall(...)

Tous les messages sont affichés d'un coup, et le script s'interrompt une fois tous les messages affichés. Ca marche bien quand les modules peuvent être testés un par un. Exemple : rien ne sert de vérifier que les modules Gnome sont présent si X11 et/ou Gtk sont absents.

Les PEP écrites par Oliphant sont :

http://www.python.org/dev/peps/pep-0209/ -- Multi-dimensional Arrays

http://www.python.org/dev/peps/pep-3141/ -- A Type Hierarchy for Numbers

http://www.python.org/dev/peps/pep-0357/ -- Allowing Any Object to be Used for Slicing

http://www.python.org/dev/peps/pep-3118/ -- Revising the buffer protocol

La PEP 209 a été rejettée si j'ai bien compris.

Le PEP 357 a été implementée dans Python 2.5.

La PEP 3118 a eu sa branche Subversion : « py3k-buffer ». Travis a fini son travail et a mergé avec trunk mi-août (2007, ça fait donc parti de Python 3.0a1).

La PEP 3141 dépendait de la PEP 3119 (classe abstraite) qui a été implémentée. J'ai vu passer plusieurs patch pour cette PEP mais elle ne semble pas encore implémentée, ça avance doucemennt.

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...

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. Pour les modules écrit en C, je ne sais pas. Je pense que d'avec des #ifdef, on doit pouvoir s'en sortir.

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.

J'ai aidé à porter le module email. Son gros défaut est qu'il mélangeait allègrement octet et caractère, chose totalement fausse d'un point de vue conceptuel. Disons que ça marche (en Python2), mais que le comportement est parfois inattendu...

Un gros travail a été fait sur le module et il a été intégré de justesse à la version alpha 1.

Porter un module pour Python3 implique de recadrer certaines choses, et ça va dans le bon sens.

Casser toute la compatibilité d'un coup n'a aucun sens.

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

Exemple 1

Mélanger des octets (str) et caractères (unicode) est source de bugs difficile à corriger. Python2 autorise la comparaison entre un octet et un caractère, ce qui conceptuellement n'a aucun sens. Python3 lance une erreur TypeError (can't compare bytes and str).

Exemple 2

0666 est lu comme 438 par Python2, sauf que ça peut dérouter les débutants qui saisissent 001, 002, (...), 008 => SyntaxError. Python3 exige le préfixe « 0o » (zéro, lettre O) : 0o666.

Exemple 3

Les méthodes values() et items() d'un dictionnaire sont des itérateurs. Ceci évite que « for key, valeur in data.items(): ... » ne crée une liste temporaire qui peut peser lourd en mémoire, prend de temps à être créée. En plus, si ça se trouve la boucle va être interrompue à la 2e itération ! On pourra toujours obtenir une liste mais avec la syntaxe générique « items = list(data.items()) ».

Exemple 4

De nombreux ajouts visent à durcir les contrôles du typage. L'annotation des fonctions permettra d'indiquer le protoype d'une fonction et les classes abstraites peuvent servir d'interface.

Plutôt que d'être taquin pasBill pasGates, pourquoi tu n'as pas écrit une version francophone directement car tu sembles apparement être fluent en anglais ? Cela servirait à tout le monde.

Rah enfoiré, t'as déjoué mes plans diaboliques !

Au téléphone, un ami m'a aidé à retrouver la mémoire :
http://www.wikio.fr/

Le site existe encore.

J'avais déjà vu un site similaire dont j'ai oublié le nom. C'était un aggrégateur de RSS + des news postées par les utilisateurs. Tout était trié par le nombre de clics, les votes utilisateurs et d'autres paramètres que je connais pas (je suppose la date de l'insertion). Non, ce n'est pas linuxfr, c'était un site généraliste avec "wiki" dans le nom de domaine je crois.

J'étais trouvé ça pas mal, mais ça boguait (web 2.0 qui marche pas sous Konqueror) et puis j'suis tombé amoureuuuuuu d'Akregator.

Victor

Personne n'a souligné que Python 3000 est 33% plus lent que Python 2.5 : « The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 33% slower than Python 2.5. ».

Je vois que la guerre de l'indentation n'est pas morte et c'est bien pour ça que Python 3000 ne change rien. Perso, je serai pour interdir les mélanges tabulations / espaces dans le même fichier. Chacun a ses raisons (qu'il trouve très bonne) pour utiliser l'un ou l'autre. Par contre, c'est vraiment le bordel quand on mélange les deux dans le même fichier ! Voir les exemples de Matthieu Moy pour celà.

--

Maintenant pour contribuer au troll, les arguments de Moonz ne sont pas recevables.

> Si tu règle ta tabulation à 2, essayes par exemple
> $ cat ton-fichier.py
> $ a2ps ton-fichier.py
> ...
1. man sed

Ah ouais super... il faut utiliser sed pour contrôler l'effet pervers des tabulations. Super quoi.

2. Le rendu dépend aussi de la police utilisée

C'est hors-sujet ça. Rien à voir avec le conflit espace/tabulation.

> Et au passage, dis-moi comment tu tu rends compte quand ton code dépasse 80 colonnes.
À tout hasard, dépasser les 80 colonnes (ce n'est plus que rarement respecté de toutes manières) ?

Respecter une limitation à 80 caractères est une bonne pratique pour garder un code lisible. Car le mode "wrap" est souvent pénible à utiliser. Et puis, quand on dépasse 80 caractères, c'est parfois que le code pourrait être reformulé plus simplement.

Le propos des tabulations est justement de coder sans se préocupper de la présentation visuelle

C'est bien naïf ça. L'aspect visuel du code apporte des informations sur l'organisation du code. En C, on peut écrire un programme sans aucun retour à la ligne (mis à part les #include et #define). Voir le concours IOCCC pour voir ce que donne les cas extrêmes.
http://www.ioccc.org/

Mais en aparté, c'est tout de même la seule situation ou je m'autorise le mix tab/espaces en Objective-C:

C'est bien là que le bas blaisse. Tu avoues toi même avoir besoin de mélanger espace et tabulation. Or c'est exactement là que les tabulations foutent la merdent car elles perdent tout leur intérêt ! Voir l'expemple ci-dessous :

T[sendSomeLongMessage: arg1
TSSSwithManyArguments: arg2
TSSandAnotherArgument: arg3
TSSSSSSSSmoreArgument: arg4
TSSScontinueArguments: arg5]

Alors tu expliques dans tes longs commentaires que les tabulations c'est la solution au problème de mise en forme pour la simple et bonne raison que l'utilisateur peut choisir la largeur des tabulations. Or tu démontres que tu VEUX que le code soit bien indenté au caractère près et utiliser pour cela des espaces.

Prend ton exemple et modifie la taille des tabulations (1, 4, 8, 20 espaces). Tu ne vois rien qui cloche ? L'indentation est brisée.

Que mon code sera lisible dans tout éditeur sachant gérer les tabulations correctement.

Il fallait lire : « mon code sera lisible dans tout éditeur ÉTANT CONFIGURE EXACTEMENT COMME LE MIEN » et c'est là qu'on retrouve les horribles pied de page qui indiquent la configuration vim/emacs.

Mais à part cette situation,

C'est pourtant exactement pour cette situation (pourtant très courante) que les tabulations c'est de la merde en sac.

J'avais aussi entendu parler de la réorganisation des modules standards, sais-tu ce qu'il en est ?

Certians vont disparaitre et d'autres vont maigrir. Il doit y avoir une PEP qui détaille ça, disons :
http://www.python.org/dev/peps/pep-3001/

Ce travail n'est pas encore fait mais le sera avant août 2008.

Python 3000 est la première version qui décide de faire table rase du passé et de supprimer les erreurs de jeunesse.

Les identifieurs (variables,...) ne sont plus limités aux caractères ascii

Certains vont tomber de leur chaise en lisant ça : « Mais... mais... comment je vais faire pour utiliser une bibliothèque écrite en tibétain, vietnamien ou encore coréen ? mon clavier est frappé d'un coq et n'a que quelques lettres accentuées ! ». La réponse est simple : c'est à l'auteur de choisir d'utiliser des noms ASCII (a-z, A-Z, 0-9, _) ou bien des noms unicode (dans leur langue). C'est l'auteur de la bibliothèque qui décide si d'autres pourront le relire ou non. Quelqu'un qui écrit du logiciel libre et veut des contributeurs écrira forcément en anglais avec des noms ASCII.

Une nouvelle alternative à l'opérateur '%' a faite son apparition, str.format().

format() a l'air surpuissant ! Pour l'internationalisation d'un programme, on peut aisément changer l'ordre des arguments dans la chaîne de formatage car les arguments sont numérotés (ex: "{0} {1}!".format('Hello', 'World')). En fait, c'était déjà plus au moins possible avec printf() mais beaucoup plus tordu. format() est très personalisable au niveau des rêgles de formatage. Lire la PEP pour les détails.

bytes ne peut pas être utilisé comme index d'un dictionnaire.

Pour ceux qui parlent le Python, on dit que le type mutable est mutable. C'est-à-dire qu'on peut le modifier : « x=b"abc"; x[0]=42 » ce qui n'était pas possible avec le type str de Python2. Conséquence : le type bytes n'est pas hashable, or la clé d'un dictionnaire doit être hashable. J'ai posé la question de comment faire pour avoir un bytes non modifiable mais je n'ai pas bien compris la réponse. On m'a parlé du l'outil « buffer » ou du type batard « str8 » (qui est en fait l'ancien type str mais ce dernier ma disparaitre). Pour des raisons de compatibilités avec Python2 ou pour pouvoir utiliser bytes comme clé de dictionnaire, ça serait bien d'avoir un frozen_bytes.

Annotation de fonctions

Un des objectifs est de permettre d'annoter les types des arguments et type de retour pour permettre aux outils tels que pychecker de vérifier les erreurs de typage.

Faire de print une fonction a beau être une bonne idée pour la cohérence du langage,

C'est surtout pour permettre de remplacer la fonction par du code perso. On peut très bien écrire « print = logging.info » pour transférer la sortie dans le système de logging !

Haypo