Victor STINNER a écrit 1639 commentaires

Non c'est un vrai problème (qui est en discussion sur python-devel et qui selon moi est fondamental).

Effectivement, ce point épineux a provoqué des discussions assez houleuses sur la liste de diffusion. Il y a trois choses : sys.argv, noms des fichiers, et les variables d'environnement. Pour l'instant, tout est accessible en Unicode.

Pour les fichiers, j'ai écrit un patch pour pouvoir utiliser des noms de fichier sous forme d'octets. Ce travail a pris plusieurs mois mais a été intégré pour la sortie de la version 3.0 finale.

Pour les variables d'environnement (comme PATH), c'est en cours de discussion. Je pense que la version 3.1 pourra accéder aux variables d'environnement en tant qu'octets. Pour sys.argv, personne ne s'en est plaint (pas de bug ouvert, je crois) :-) Sûrement qu'à terme, il existera aussi une méthode pour accéder à la version en octets.

La solution que je déteste et que plusieurs personnes essayent à chaque fois de pousser, est de stocker des octets dans Unicode en utilisant un encodage spécial (ex: utiliser une plage réservée d'Unicode). Mais je ne comprend pas l'intérêt car on revient au status pourri de Python2 qui mélange octets et caractères, source de nombreux bugs. En particulier, le texte Unicode n'est plus interopérable :-/

À long terme, tous les systèmes utiliseront Unicode. Pour information, Windows utilise UTF-16 partout depuis très longtemps (Windows 98 je crois). Le problème est lorsqu'on mélange de vieilles partitions encodés avec des encodages différents. Il vaut mieux tout mettre en UTF-8 pour des raisons de simplicité. Python3 fait un pari sur l'avenir.

Note : Sur un système sain (UTF-8 partout), Python3 fonctionne à merveille ! C'est très agréable d'avoir de l'Unicode partout !

Le RSS Reader... (...) Un carnet d'adresse...

Tu as déjà essayé Akregator et KAdressBook ? Pour le carnet d'adresse : il est partagé avec Konversation (IRC), Kmail (mail) et Kopete (message instantanée). Du coup, tu peux voir la photo de tes amis dans IRC, l'état de présence dans l'entête des emails, etc. C'est bien intégré et très fonctionnel.

J'ai testé Lifeara sous Gnome, mais avec ~40 flux après 6 mois ça devient si lent que ça en est inutilisable. Il semble qu'il ne supprime jamais les anciens flux, même en changeant la limite. La recherche ne peut pas se faire un seul flux, elle est devient plutôt inutile du coup :-/ Autre gros défaut : impossible de savoir de quel flux vient un article !?

perso je préférai la version 3.0

Parce qu'il n'y a rien dans la syntaxe python pour déterminer explicitement le début et la fin d'un bloc.

Un automate peut quand même facilement les trouver. Python y arrive bien ;-)

Avec Python 2:

>>> print "a", "b"
a b
>>> print ("a", "b")
('a', 'b')

Je trouve ça moche : selon la présence de parenthèse ou non, le résultat est différent. Alors qu'habituellement, rajouter des parenthèses ne change rien. Exemple : « x = 1, 2 » et « x = (1, 2) » sont synonymes.

Ton argument est « avant c'était bogué, il faut que ça reste bogué ». Ça me fait penser aux bugs HTML d'Internet Explorer... Justement, Python3 fait table rase de vieilles horreurs pour homogénéiser le langage.

même bien indenté ton code peut ressembler à rien ( saut de 10 lignes, commentaires, lignes trop longues et autres, mélanges espace tabulation...

Tu peux tronquer les lignes trop longues, je vois pas le rapport avec l'indentation. Tu coupes là où tu veux et tu mets « \ » en fin de ligne (souvent, même pas besoin de l'antislash). Je ne connais pas d'outil pour ça, mais en même temps je n'ai jamais lu de tel code (mais vu le nombre de légendes, ça doit exister :-)). Je pense qu'il existe des outils pour faire ça.

Pour uniformiser espaces et tabulations, Python intègre l'outil tabnanny.

Le jours ou tu voudra rajouter une condition, tu vas sélectionner un paquet de ligne indenter, et au passage oublier une ligne...

Je pense qu'un bon éditeur Python sait trouver la fin d'un bloc. Perso je le fais à la main avec vim : sélection des lignes à indenter puis commande < ou >.

Bien sûr, si le bloc fait 934 lignes, c'est plus dur. Mais là il faudrait penser à nettoyer un peu le code :-)

L'horrible « print "a", » (notez la virgule à la fin) était plutôt sale, je préfère « print("a", end=' ') » ou print("a", end='') ».

La syntaxe « print >>sys.stderr, "bla" » était un cas très particulier en Python : seul print utilise cette syntaxe. Maintenant la syntaxe est uniforme : « print("bla", file=sys.stderr) ».

Le mot clé print empêchait de définir une méthode print dans une classe.

print ("a", "b") prêtait à confusion : c'est un tuple de deux valeurs ou deux valeurs ? (afficher "a b" ou "('a', 'b')" ?) Avec Python3, il n'y a plus de doute possible.

print n'était qu'une longue liste de cas particuliers foireux.

Serveur qui écoute sur le port 8080 : évalue l'expression Python saisie et renvoie le résultat.

l=lambda(i):lambda(l):i.__getattribute__(\
O(l));i=lambda(i):l(__import__(O(i)));j=(\
ord,''.join);o=lambda(l):i('speniy')(l);O\
=lambda(I):j[1](chr((j[0](l)-i)%0x100)for\
(i,l)in(enumerate(I)));k=i('_`dxmqzpvhi')\
;k=(k('rbpji'),k('ewco'),k('ljuw'),l(o(''\
'speniy')(o('AGaLRJZ'),o('SPENcXZYMJW')))\
);I=i('iuguxtus{')('tbmh{mosm');i=l([k[-1\
](i[0])(*i[1:])for(i)in(('sfvvshqvx}',o(\
'SPNbWTIRM]'),o('SPaUIZYLIMN]'),1,),('bj'\
'pg',('',010*1010),),('ljuwis',1),('adeh'\
'ty',))][-1][0]);k=k[:-1];i=(i('rfey'),i(\
'sfpg'));k[-1](i[1]("%s\n"%k[1](j[-1](I(\
lambda(I):j[0](I)^10,(i[0](1)for(k)in(k[0\
](101)))))))for(O)in(k[0](1010)))

Tiens, il n'y a aucune espace.
http://haypo.hachoir.org/trac/browser/misc/obscu.py

Si quelqu'un écrit une dépêche, je veux bien lui filer un coup de main. Par contre, je suis pas trop chaud pour prendre l'initiative. Le plus simple : me parler sur Freenode (IRC), nick haypo.

J'ai testé un installation où tout était chiffré : installation avec une seule partition qui contenait tout. Bah c'est hyper lent. top montrait souvent le processus noyau qui chiffrait le disque. Bref, à éviter à tout prix. Il ne faut que chiffrer l'essentiel : /home voir une partie de /home. Chiffrer la partition swap coûte aussi cher en CPU. Vaut mieux acheter une barrette de RAM en plus.

Niveau accessibilité, l'URL m'indique « Service Temporarily Unavailable ». J'ai connu mieux en matière d'accessibilité...

Le jeu tourne sous Linux, mais ça n'en fait pas un logiciel libre pour autant. Autant faire une fiche sur le site http://www.happypenguin.org/ ou http://www.linuxgames.com/

Pour les jeux libres, il y a http://jeuxlibres.net/ D'ailleurs, c'est bizzare : les sites anglophones acceptent les jeux fermés et les sites francophones les refusent ? ;-) (c'est une manière de dire que jeuxlibres.net mériterait une traduction pour une meilleure visibilité)

Les releases devraient intégrer directement le module Ui_pymecavideo et la doc compilée. Càd lancer make avant de faire le tarball) tout simplement.

We don't know when or if this item will be back in stock.

Ahem, on est bien le 17 novembre ? Le produit ne semble pas être en vente depuis amazon.fr.

« Nous n'appartenons à personne. » - Bertrand Cantat
http://www.rockademy.com/noir_desir.html

« Nous vivons sur la même planète, mais nous ne sommes décidément pas du même monde » - Bertrand Cantat, 2002
(Il parlait à l'ancien président de Jean-Marie Messier, président de Vivendi Universal, distributeur et producteur de Noir Désir)

LCC 4.2 est donc sorti depuis le 19 Juin 2003.

Par contre,
$ svn info http://drh.svnrepository.com/svn/lcc/trunk/
Révision : 561
Auteur de la dernière modification : drh
Date de la dernière modification: 2008-09-27 07:27:35 +0200 (sam, 27 sep 2008)
...

Donc le projet n'est pas mort.

Dans l'article du journal Le Parisien : http://www.leparisien.fr/loisirs-et-spectacles/noir-desir-re(...)

J'ai mis une copie du fichier sur mon site perso :
http://neudorf.hachoir.org/tmp/Gagnants - Perdants, et Le temps des cerises.rar
99cc4556d92d91698654f698768abba6 Gagnants - Perdants, et Le temps des cerises.rar

J'en ai codé un en Prolog pour un cours d'intelligence artificielle. J'ai trouvé que Prolog était bien adapté aux systèmes experts. Par contre, PHP, boarf :-)

Middle End Lisp Translator !
http://gcc.gnu.org/wiki/MiddleEndLispTranslator

Le but est de faire de l'analyse statique du code (comme SPlint, pyflakes, etc.). Tiens, ça me rappelle une conférence GCC aux RMLL 2008 :
http://2008.rmll.info/Projet-GGCC-Global-GCC.html
http://2008.rmll.info/IMG/pdf/ggcc_rmll2008_2.pdf

Ce greffon GCC fait parti d'un projet plus vaste : GlobalGCC, soutenu (financé ?) par le Ministère de l'industrie, du tourisme et du commerce espagnol, Ministère de l'Économie des finances et de l'emploi français, EUREKA et ITEA2. Les objectifs de ce projet sont :
- l'analyse statique de code (MELT donc)
- validation de règles de programmation (style de programmation ?)
- optimisation globale

Sur le dernier PC que j'ai acheté neuf chez Darty, ni la carte Ethernet gigabit Realtek RTL8111/8168B PCI, ni la carte graphique Intel Q33/Q35/G33 n'étaient reconnues par une Debian stable, alors qu'un noyau Linux récent installé à la main les accepte.

J'ai acheté un PC neuf sur lequel j'ai installé Ubuntu Ibex. Et bien la carte réseau Realtek RTL8111c (carte gigabit intégrée sur la carte mère) fonctionne très bien ;-) Je dois avouer que j'ai bien vérifié le chipset 3x avant d'acheter la carte mère parce qu'un ami a récemment acheté un carte mère dont la carte réseau ne fonctionne pas sous Linux (oups !).

« le temps de compilation entre gcc3 et gcc4 a pu doubler (...) Et c'est super pénible, surtout en C++ (...) et ça donne envie d'utiliser des langages interprétés. »

Tiens, c'est exactement pour ça que je suis passé du C++ au Python :-) Le C++ est quand même un cas particulier avec ses horribles templates qui augmentent considérablement le temps de compilation. D'ailleurs, il me semble que les autotools n'exploitent toujours pas la précompilation des entêtes C++ :-( Quand j'utilise Borland C++ Builder, la précompilation des entêtes faisait passer le temps de compilation de 5/10 minutes à 60 secondes.

rien à voir avec OpenBSD ou Theo

Interview de Theo au sujet de PCC (et GCC) :
http://www.thejemreport.com/content/view/369/

Extrait : « we hate large code, and buggy code that upstream does not maintain (...) gcc gets about 5-6% slower every release, has new bugs, generates crappy code, and drives us nuts »

Critique de GCC par Marc Espie du projet OpenBSD :
http://undeadly.org/cgi?action=article&sid=2007091519520(...)

Tu vois pas le rapport ?

Hum, PCC est un compilateur C, soit. Mais de là à oser dire qu'il est un concurrent à GCC, faut pas abuser. Comme dit dans les commentaires précédents, GCC est très portable, rapide, et gère un nombre considérable de langages différents. J'aime beaucoup les avertissements GCC (-Wall -Wextra -Werror). Exemple : il râle si on oublie un argument à printf ou si un argument n'est pas du bon type. Ce genre de détail est un gain énorme en temps de debug !
http://www.haypocalc.com/blog/index.php/2007/12/03/85-option(...)

PCC n'est plus maintenu depuis longtemps (Theo semble dire l'inverse, que GCC n'est plus maintenu) : ce n'est que récement que PCC renait de ses cendres. Pour moi, c'est plutôt un coup marketing : OpenBSD ne veut que du code BSD quitte à réinventer à la roue (carrée) et user de FUD sur ses concurrents.

J'avais dressé une liste (sûrement incomplète des compilateurs C libres) :
http://www.haypocalc.com/blog/index.php/2007/10/02/77-compil(...)

Apparement, le seul qui puisse atteindre le niveau de GCC est LLVM. Ce dernier n'est pas spécifique au C, Apple l'utilise déjà pour compiler des shaders (code pour les cartes graphiques). Il sait faire de la compilation à la volée (JIT). Il y a un projet (PyPy) qui l'utilise pour compiler du Python. Bref, rien à voir comparé à la blague qu'est PCC.

pourquoi faut-il écrire 3 fois 'nom' et 3 fois 'prénom'

Euh, c'était juste pour l'exemple :-) Pour montrer que Python3 autorise unicode partout : aussi bien dans les chaînes de caractères sans avoir à les préfixer par "u" (unicode), dans les noms de variables, dans les noms d'arguments, etc. Habituellement, j'utilise "Bonjour %s %s" % (nom, prenom) (compatible avec toutes les versions de Python) ou "Bonjour {0} {1}".format(nom, prenom) quand je hacke Python 2.6 ou 3.0 :-) En fait c'est faux, je n'écris jamais nom, mais plutôt name :-)

Je pense que la fonction vise plutôt les formations dans la langue maternelle des élèves ou les entreprises qui développent du logiciel propriétaire. Pour un logiciel libre, bien que l'espéranto soit séduisant, l'anglais est la langue la plus répandue dans l'informatique. Un petit exemple pour la route :
>>> nom = input("Nom ?")
Victor
>>> prénom = input("Prénom ?")
Stinner
>>> print("Bonjour {nom} {prénom}".format(nom=nom, prénom=prénom))
Bonjour Victor Stinner
Équivalent Python 2.x :
>>> charset = "UTF-8"
>>> nom = unicode(raw_input(u"Nom ?"), charset)
Victor
>>> prenom = unicode(raw_input(u"Prénom ?"), charset)
Stinner
>>> print(u"Bonjour {nom} {prenom}".format(nom=nom, prenom=prenom))
Bonjour Victor Stinner
C'est tout de suite plus laid non ? :-) L'orthographe ne peut pas être respectée, c'est dommage. Et encore, mon heuristique pour déterminer le charset du terminal est pourrite : c'est toujours UTF-8 :-) Il faudrait utiliser une fonction pour ça qui n'est pas incluse de base de dans Python 2.x :-/