Victor STINNER a écrit 1632 commentaires

J'utilise vim. Pour le code C, ^] (avec ctags) est pratique pour aller à la définition d'une fonction. Pour le code Python, j'aimerai bien savoir comment aller au début/à la fin d'une fonction/classe Python, mais je me débrouille autrement (je cherche "def " et "^class "). Pendant une dizaine d'année, j'ai développé sans la complétion. Maintenant j'en abuse, ça évite les fautes de typo à la con.

La JVM, .NET, ce ne sont pas des projets pilotés par la communauté...

Mono est un logiciel libre non ? Mono gère beaucoup de langages et pas que des langages statiques : http://mono-project.com/Languages

Au vu des problèmes qu'il y a eu dessus depuis leur apparition, je suis bien content que la communauté Perl essaye une autre voie.

À quels problèmes tu fais référence ? (je ne suis pas l'actualité des VMs)

LLVM, ce n'est pas si ancien que cela et en plus, il y a Apple derrière...

Tu veux dire que c'est un défaut que LLVM soit récent ? Parrot est plus ancien que LLVM ?

Pour Apple : tant mieux qu'une société paie des développeurs pour améliorer un logiciel libre. Apple utilise LLVM pour compiler les shaders des GPU sous Mac OS X. Bah Xorg fait maintenant pareil avec Gallium. J'en comprends qu'Apple a indirectement contribué à Xorg (ou dumoins à LLVM).

Par ailleurs, c'est quand même à la base fait pour faire de la compilation de langage statique.

Effectivement, la JVM, .NET et LLVM sont plus à l'aise avec des langages statiques. Mais je ne suis pas sûr qu'écrire une nouvelle VM se voulant générique et adapté à tous les langages (surtout les langages dynamique) est un projet réaliste. Il faut y aller petit à petit. Parrot a été lancé depuis longtemps et il semble que l'implémentation de Perl6 (qui est liée à Parrot) ne soit pas encore terminée, et c'est le seul langage majeur supporté. En plus, j'ai entendu que les performances de Perl6 ne sont pas fameuses, le JIT ne Parrot ne semble donc pas très avancé.

Bien sûr que Parrot est une belle idée. Bien sûr que ça serait génial d'avoir une implémentation de Python pour Parrot. Mais qui va l'implémenter ? Est-ce qu'il y a suffisamment de développeurs motivés pour aller jusqu'au bout ? Quel en est l'intérêt comparé aux autres solutions ? Perso j'attends de voir des résultats intéressants avant de m'y plonger. Pour l'instant, le seul truc que j'ai vu est que l' "assembleur" me semble assez proche du langage Perl.

ce serait bien que ça pousse à sortir quelques outils (notamment pour la recherche de paquets)

À ce que j'en ai compris, distutils2 ("packaging") est livré avec un outil pysetup qui permet de lister les paquets installés (entre autres, ça peut faire plein de trucs). Sinon y'a une API simple pour faire la même chose. Si pysetup répond déjà à tous les besoins, je ne suis pas sûr qu'il soit encore nécessaire d'avoir plusieurs outils (incompatibles ?) pour cette tâche. J'espère d'ailleurs que pip va fusionner avec distutils2 (il me semble que c'est bien parti pour).

wxpython par exemple n'est pas installable via distutils/distribute/pip

distutils2 ne résoud pas tous les problèmes. Un projet comme wxPython est autrement plus compliqué à packager qu'un petit projet ayant juste un fichier Python, notamment car il doit être compilé, a sûrement des dépendances non-Python, et le binaire résultant est spécifique à un OS (voir à une version précise de l'OS). Les distributions Linux ont déjà de super outils pour packager tout et n'importe quoi. Sous Mac OS X et Windows, il faut tout faire soit même.

j'ai du mal à comprendre les critiques de Twisted

Perso, c'est la syntaxe des callbacks qui me dégoûte. C'est difficile à écrire et encore plus difficile à déboguer (surtout les errbacks !).

Python vs Ruby

Je pense pareil que pour Python vs Perl : c'est le même langage, mais avec une syntaxe différente, et comme Perl : Ruby privilégie l'implicite (mais un peu moins que Perl) à l'explicite. On m'a d'ailleurs dit que Ruby On Rails repose essentiellement sur des conventions, je n'en sais pas plus :-)

De mon expérience, un projet est vite écrit, mais devra être maintenu plusieurs années, et parfois le(s) développeur(s) initiaux quittent le projet. La priorité pour moi est la maintenance sur le long terme, et la lisibilité de Python est très importante pour moi.

Il existe le projet https://bitbucket.org/allison/pynie

Je trouve dommage que le langage python (ruby...) mise pas plus sur la machine parrot pour la couche basse

Quand tu écris "le langage", tu veux dire les développeurs Python ? Ou bien la fondation Python (PSF) ? La fondation Python a donné un chèque de 10.000$ à PyPy lors du dernier PyCon US (mars 2011). PyPy est déjà compatible à 100% (ou disons 99,999%) avec CPython et plus rapide que CPython sur de réelles application (dans certains cas). Il me semble plus rentable d'investir du temps et de l'argent dans PyPy que dans Parrot.

Il existe des implémentations de Python sur la JVM (Jython) et .NET (IronPython). Mono a également pour objectif d'être la VM de tous les langages. Pourquoi Perl n'investit pas plus de temps de ressources dans Mono plutôt que de recoder (depuis zéro !) sa propre VM ?

Il y a également eu des expérimentations avec LLVM (Unladen Swallow et une des premières implémentations du JIT de PyPy), mais les résultats étaient décevants.

Python a beaucoup de particularités qui font que c'est un langage difficile à optimiser. PyPy semble avoir trouvé une voie qui donne des résultats concrets.

Vu la complexité des algorithmes cryptographiques actuels, on peut considérer qu'il y aura toujours une faille dans la bibliothèque X ou Y.

C'est plutôt dans les protocoles comme TLS ou dans la gestion des certificats que des failles sont trouvées plutôt dans les implémentations des algorithmes de chiffrement.

\_o< coin

Bah si tu te logues en root, "cd<entrée>" suffit ! (3 touches), plus rapide que "/r<tab><entrée>" (4 touches) :-)

Ah oui, c'est Pause ou Verr. num. pour lancer Duke Nukem Forever. Wow, les graphismes sont bluffant ! Ça met un peu minable à Linux avec ses pilotes qui font pas du tout à fait de la 3D de qualité. Par contre, le ventilo du CPU bosse à donf (on peut pas tout avoir). Une version complète est prévue ?

Cet OS est vraiment extrêment rapide à booter (c'est le plus rapide que j'ai jamais vu). Par contre, je ne trouve pas comment lancer Duke Nukem Forever ni comment passer en AZERTY.

# dnk
dnk: Computer bough the farm
# ls
ls: Computer bough the farm
# cd /bin
cd: Computer bough the farm

Il existe un autre langage monolettre méconnu, le "C".

Pourquoi Hedgewars plutôt que Hurd ? Je crois que Hurd a plus besoin de main d'œuvre que Hedgewars !

Perso je préférerai largement le changelog sous forme de diffs plutôt qu'avec tout le paragraphe (difficile de voir les changements). diff -u ou wdiff ?

Tout à fait d'accord, c'est deux régressions graves par rapport à l'ancienne version de linuxfr.org

Effectivement, Python 2.7 également. Mais ça n'empêche pas d'avoir l'imprécision lié aux conversions entre les bases 2 et 10 à certains moments.

Certains processeurs IBM savent faire du calcul sur nombre flottant en base 10, comme les Power6 et Power7 : http://speleotrove.com/decimal/

Pour les pauvres, il y a le calcul en logiciel :

$ python
>>> 2+.4
2.3999999999999999
>>> from decimal import Decimal
>>> 2+Decimal(".4")
Decimal('2.4')

Un certain nombre de langage bien connus utilisent des nombres réels et non des nombres naturels comme type de base pour les nombres. C'est le cas pour PHP, Javascript, XML (XPath), etc.

Hum ? PHP distingue clairement 1 (type int) et 1.0 (type float).

$ echo '<?php var_dump(1); var_dump(1.0); ?>'|php
int(1)
float(1)

Pour un langage tel que Python qui ne prétend pas surprendre, qui fournit par défaut un type numérique au delà des 2³², ...

Python 2 a deux types pour les nombres entiers : int et long. Avec Python 3, il n'y a plus qu'un seul type : int (qui est en fait le type long de Python 2). Je ne comprends pas ce que tu appelles "type numériqué" : un nombre entier ou flottant ?

Il existe une branche py3k-jit qui vise à intégrer le travail d'Unladen Swallow dans Python 3. Le dernier commit dans cette branche date de 8 mois, et c'était un merge.

Il existe aussi la PEP 3146: Merging Unladen Swallow into CPython.

Ça ne semble pas trop avancer...

Par contre, certaines optimisations faciles à intégrer font déjà parti de Python 3.2, je pense notamment à l'énorme optimisation de pickle citée dans la dépêche.

Tous les langages, à ma connaissance, donnent 0 pour « 1/2 »

Donc tu considères, par exemple, qu'Octave n'est pas un langage ? :-)

octave:1> 1/2
ans =  0.50000

Python est de plus en plus utilisé dans le milieu scientifique, notamment grâce à NumPy+SciPy, et 1/2 qui donne 0 fait un peu tâche.

Comme chaque changement majeur du langage, ce changement sur la division s'est fait via une demande d'amélioration de Python (PEP) : PEP 238: Changing the Division Operator. Cette PEP explique en détail pourquoi ce changement était nécessaire.

J'ai remonté l'info, ça a été corrigé.

Si tu vas lire le 2e lien de la dépêche, tu risques de tomber sur la section suivante en te faisant mal : PEP 3333: Python Web Server Gateway Interface v1.0.1.

Il y a eu des discussions houleuses au sujet de WSGI en Python 3, oui, mais un consensus a été trouvé : la PEP 3333 (WSGI "1.0.1") a été acceptée. Les modules cgi et wsgiref ont d'ailleurs été lourdement corrigés améliorés dans Python 3.2.

WSGI 1.0.1 est un sale hack, ou "consensus" (pour être politiquement correct), pour offrir une meilleure compatibilité entre Python 2 et Python 3. La prochaine version de WSGI séparera correctement octets et caractères pour mieux exploiter les possibilités offertes par Python 3 avec sa dictinction entre les types bytes et str. Par contre, je n'ai pas assez suivi le sujet pour pouvoir donner des pointeurs pertinents vers la nouvelle version brouillon de WSGI. Il semble qu'il y ait plusieurs équipes qui se livrent une guéguerre en disant que leur WSGI 2.0 est mieux :-)

Blender exige Python 3 depuis sa version 2.5. Eric 5 (IDE pour Python) est écrit en Python 3.

BIND 10, projet en cours de développement, peut être scripté en Python 3.

Je prends ça comme un compliment.

Avec Templeet, les dépêches LinuxFR étaient écrites dans un pseudo-HTML, difficile à maitriser. Il y avait de nombreuses subtilités sur les retours à la ligne. Pour obtenir un rendu correct, il fallait supprimer les retours à la ligne autour des listes, ce qui donnati un code HTML illisible. Markdown est un énorme soulagement pour moi !

Plusieurs modérateurs peuvent maintenant éditer différentes parties (paragraphes) d'une même dépêche, ce qui évite le gros verrou sur l'ensemble du texte qui ralentissait la relecture.

Comme le code source du nouveau site web est plus récent et réutilise un framework existant, il est fort à parier que les nouveaux (et anciens ?) bugs seront corrigés plus rapidement qu'avant.

Perso quand je supprime un fichier source par erreur, je vais le récupérer sur github ou bitbucket où y'a une copie gardée bien au chaud :-)