C'est parti pour Python 3000 : http://www.python.org/download/releases/3.0/
 
La PEP 3000 est ici : http://www.python.org/dev/peps/pep-3000/
 
Van Rossum répond à différentes questions sur Python 3000 :
http://www.artima.com/forums/threa [...] ead=211200
http://www.artima.com/forums/flat. [...] ead=211430
 
 
Je viens juste de charger la tarball et de compiler la 3.0a1 : ça marche !    

et ? Tu veux faire quoi d'une nouvelle version avec des changements aussi débiles que le passage de print en fonction ou aussi pernicieux que de changer le sens de la / pour les noob ... Tout foutre en l'air pour ça, ouah trop bien.
 
Surtout que les performances sont toujours très mauvaises, et que déjà on trouve des portables quad-core: mais non, on nous explique que le modèle de threads python avec son GIL est le meilleur et même plus plus performance. Voire on FUD sur le fait que le multithreading c'est dangereux et que c'est la porte ouverte à l'apocalypse.
 
J'espère que toussa va foirer et que ça se fera écraser par un truc comme Jython ou IronPython avec une vraie VM derrière.

Lu
 
Perso je trouve les changements de la 3 assez chiants, va falloir repartir de zero pour pleins de trucs comme les manips surs les strings etc...
 
Les perfs de Python sont sympas je trouve, en tout cas pas gênantes sur des petites apps, sur que sur des gros trucs ou des calculs complexes/3D ça peut pénaliser, dans ce cas teste Psyco

Et apparement, même si le script 2to3 n'est qu'en alpha il ne marche apparement pas trop mal: http://intertwingly.net/blog/2007/09/01/2to3

Oui enfin si ça c'est un changement bloquant ça va devenir dûr

Le sens actuel de "/" n'est pas logique (surtout pas pour les "noob" justement) et pas pratique (tu fais plus souvent des divisions entières que vraies toi? parce que moi non, les rares fois où je fais des divisions), je trouve ça très bien le passage à une vraie division  

Les performances de Python (pas exactement vrai quand on compare aux autres langages dans la même catégorie ou les performances de Python 3 (ça par contre c'est vrai comparé à 2.5)?

C'est complètement vrai ça, le multithreading c'est merdique  

Fais du Ruby Java, ya rien qui change jamais

Ils sont chiants, mais personnellement je trouve qu'ils sont nécessaires.
 
Oui le langage change, parfois violement (en même temps on le savait, Python 3000 a toujours été considéré comme l'occasion de changements majeurs, ils sont d'ailleurs au final beaucoup moins majeurs qu'initialement prévus), mais personnellement je considère que c'est nécessaire si Python ne veut pas devenir un nouveau Cobol comme ce que Java est en train de faire.
 
La disparition de la dichotomie "old-style classes"/"new-style classes", une gestion complète, intégrale et unifiée de l'encodage avec un encodage unicode par défaut (et plus ascii), un type byte correspondant à des bytes et pas à des caractères, le nettoyage de nombre de builtins (disparition des backticks, de "<>", de "input" remplacé par un équivalent au "raw_input" actuel, la méthode `next()` des itérateurs devient `__next__()`), l'unification des ints et longs, l'ajout de cohérence au niveau de valeurs de retours (plus de lists, tout passe en iterators) je trouve ça très bien perso. Ca va faire mal pendant le passage (en même temps la transition commence tout juste et un a au moins 1 an avant la sortie de 3.0 final), mais je vois Python 3 comme un langage plus propre, plus simple et plus cohérent.
 
Un retour aux sources, en fait.
 
Je regrette juste une chose, c'est l'ajout d'un nouveau mode de formattage de strings, ce qui porte le nombre de méthode de formatting natives à 3 (%-format, Template et {}.format)

N'oublions pas SciPy/NumPy  

Bon je bataille pas sur tous les points.
 
Juste niveau performance : sortez de votre cave. Prenez un programme serveur en python : il est incapable de tirer partie des config multiprocesseurs. Si en plus on regarde le computer language shoutout, CPython a vraiment rien pour lui. Y a pas de catégories : il n'y a des langages et des implémentations.
Le threading est tellement merdique que personne l'utilise en python, c'est bien connu. Et tous les autres programmes/VM/kernel de ces 30 dernières années sont fondamentalement buggés parce qu'il n'utilisent pas de GIL et que donc ils sont le mal TM, on le sait bien. Ca fait du bien de se bouffer un bon conseil "z'avez qu'à forker". C'est pas comme si on avait inventé les threads pour moins forker... On est vraiment trop con avec nos threads POSIX.
 
Juste pour le fun, VIA avec son proco à 1W, j'imagine déjà des gars en empiler 64 dans un portable. On aura qu'à forker 64x toutes instance de programme python.
 
Je me fais pas de souci. Il faudra bien attendre une 3.2 pour que ça soit stable, d'ici là on aura bien un pypy correct à rebaser sur une implémentation potable.
Dire que ruby et ses greens threads prend le même chemin, ça me laisse perplexe. On est pas à un hypocryte prêt.

Les seuls langages n'étant pas fondamentalement buggés en terme de MP sont ceux qui n'utilisent pas de mémoire partagée explicite (Actors, CSP) ou dans tous les cas pas de locking explicite (Software Transactional Memory, (Nested) Data Parallelism)

Considérer que le modèle threading+sémaphores marche, c'est comme considérer que le PHP marche: c'est pas parce que les gens arrivent à en faire de trucs que c'est une bonne idée.

Aux dernières nouvelles non, on a inventé les threads parce que c'était plus simple d'implémenter threads + shared memory + sémaphores au niveau inférieur aux processus OS.