Moonz a écrit 3621 commentaires

> BSD a fait le choix d'une licence qui est compatible proprio
En quoi ça le rend responsable du choix de l'utilisateur ?

> C'est limite n'importe quoi pour l'aspect norme.
Ça peut aider pour éviter les implémentations involontairement foireuses. Mais je suis d'accord que si quelqu'un veut pas respecter les standards, qu'il y ait du code BSD disponible ou pas ne changera rien.

Et si je veux faire du libre non-GPL, je ne pompe pas de ligne GPL non plus ? Bel esprit de partage...

> C'est toujours pas assez ?
C'est beaucoup trop, au contraire... Et après ça, on s'étonne que Gnome (je dis Gnome, mais c'est pas le seul, hein) ait des problèmes de réactivité même sur des PC récents...

Premier argument pro-espaces que je vois qui est vraiment recevable. Je pertinentise :)
En même temps, je n'ai jamais jusqu'ici rencontré de tabulations en milieu de lignes (personnellement, si je veux aligner en milieu de ligne, j'utilise des espaces...)

format() n'apporte pas que ça, je te conseille de lire la PEP associée pour voir toutes les possibilités. De plus, avec ta méthode, on ne peut pas mélanger les %s et les %(foo)s. Avec format, c'est maintenant possible.

Un mec ou un agent du FBI ?

Et qu'il y en avait au moins trois incompatibles qui se tiraient dans les pattes...

Qu'est-ce que tu veux qu'un utilisateur non développeur foute d'un code source exactement ? Pour décorer ? Ya quand même des choses plus élégantes pour utiliser comme papier-peint ou poster :/

> C'est si rare que ça de passer par autre chose que ton éditeur de texte pour regarder du code ? T'utilises jamais "less" ?
Non, ce n'est pas rare, mais c'est pour regarder vite fait, et tant pis si les tabulations n'ont pas le mon nombre préféré d'espace puisque ce n'est pas censé casser la présentation (c'est fait pour...).

> Tu envoies jamais un patch par email ?
Heu... si. Mais quel rapport ? Un patch, ça s'envoie en pièce jointe...

> normalement dimensionnée.
Mais quel est ce "normalement dimensionnée" ? Personnellement, même en terminal je suis rarement en 80 colonnes que ce soit avec un xterm en plein écran ou sous une console avec framebuffer.

> mais il y a des tonnes de cas où la tab, c'est 8 espaces, et à peu près impossible à changer.
Je n'en doute pas. Mais un cas bloquant qui ne se règle pas en deux coups de cuillère à pot, je n'en ai jamais eu vent...

> D'ailleurs, puisque c'est un truc qui n'arrive jamais, pourquoi avoir suggéré sed ?
rarement != jamais -_-
Ce que je voulais dire, c'est que le cas "normal", c'est coder dans un éditeur. Pour les cas spéciaux, hé bien... outils spéciaux...

> Tu ne vois vraiment pas pourquoi c'est plus lisible d'avoir du code bien aligné plutôt que d'avoir des lignes de 500 caractères découpées arbitrairement par ton éditeur de texte ?
Mais non d'une pipe, si ton éditeur fait portnawak, c'est sa faute et ton problème !
Peux tu comprendre que le wrap peut se faite de différentes manières et que chacun à ses préférences ? Que du coup, laisser faire l'éditeur est le seul moyen de mettre tout le monde d'accord ? Que c'est le même problème avec l'indentation ?
J'ai l'impression que tu subis ton éditeur. Ce n'est pas normal. Si tu trouves qu'il wrappe ou indente comme un goret, configure le correctement. Pense que ce que tu trouves "wrappé comme un goret" peut être apprécié par certains, et vice versa !

> Tu ne nous a toujours pas expliqué comment tu comptais le nombre de caractères que prends une ligne, si tu considère que la tab peut faire autre chose que 8 caractères.
Je considère tout simplement la ligne sans son indentation...
Note que je ne suis pas au caractère près, vu que pour moi la règle des 80 caractères n'est pas "on doit wrapper au 80ème caractère selon des règles totalement arbitraires" mais "une ligne de plus de ~80 caractères est probablement trop complexe et devrait être simplifiée..." (en fait, je commence plutôt à me poser des questions vers 90-100, mais comme le nombre 80 semble "magique" pour toi...)

> Si tu veux indenter à 2, met deux espaces, et ça passera partout.
Oui, mais si quelqu'un qui bosse avec moi préfère 4, on fait quoi ? On tire à la courte paille ? On choisit la moyenne, 3 ? Un des deux IMPOSE sa préférence à l'autre ? Ou tout simplement on utilise des tabulations et chacun configure son éditeur comme il l'entend ?
Je te laisse devenir ce qu'on a décidé...

> mais c'est les gens qui jouent avec la configuration de leur éditeur et qui du coup, indentent n'importe comment.
À moins de le faire volontairement, il est tout aussi difficile de casser une indentation par tabulations que de casser une indentation par espaces. Ce qui est extrèmement facile de casser, c'est le mélange des deux ala GNUstep...
Tu peux configurer ton éditeur comme tu l'entends, du moins que tu utilises des tabulations tu ne casseras probablement rien. Et c'est justement l'avantage :)

> Bah, moi, j'ai pas envie de m'emmerder à utiliser sed parce qu'un autre développeur a décidé d'utiliser une largeur de tab non-standard.
c'est quoi une largeur de tab non-standard ?
mais comme je l'ai dit plus bas, si tu veux imprimer et avoir le code dans ton style préféré, indent est ton ami :)

> Ce qui confirme mon affirmation de départ : ton code sera illisible ailleurs que chez toi : du code qui tiens sur 80 colonnes chez toi va probablement dépasser chez n'importe qui n'ayant pas trifoullié sa config.
Heu... et alors ? Le monde n'est plus limité à 80 colonnes et 24 lignes depuis bien longtemps :p (même dans un terminal, d'ailleurs...). C'est une limite tout a fait arbitraire aujourd'hui...

> Bah, ça a l'air d'être un beau bordel, tes directives de codage.
Je ne marcherai pas dedans, je ne marcherai pas dedans...
Ho et puis zut, c'est le dernier jour où je peux troller, autant en profiter :)
Moins que celles de GNU :p

> Ah ouais super... il faut utiliser sed pour contrôler l'effet pervers des tabulations. Super quoi.
En même temps, il s'agit ici d'un cas spécial vraiment rare. Tu imprimes tous les jours des codes sources toi ? Je vois pas où est le problème d'utiliser sed pour ça, c'est pas comme si c'était une tache quotidienne. D'autant plus que j'aurais tendance à d'abord passer par highlight pour ça, soit dit en passant.

> C'est hors-sujet ça. Rien à voir avec le conflit espace/tabulation.
Le rapport est que même sans tabulations, si tu présentes ton code au caractère près tu risques (fotement) d'avoir des soucis à l'impression. C'est normal. Un code source n'est pas fait pour être imprimé.

> Car le mode "wrap" est souvent pénible à utiliser.
Pourquoi donc ?

> Respecter une limitation à 80 caractères est une bonne pratique pour garder un code lisible [...] . Et puis, quand on dépasse 80 caractères, c'est parfois que le code pourrait être reformulé plus simplement.
Là, je suis d'accord, mais ça n'a rien à voir avec la choucroute (tu dis que normalement ce problème ne se pose pas vu qu'on ne devrait pas faire une ligne de plus de 80 caractères, "wrap" manuel ou pas. Si le problème se pose as, aucune raison d'en discuter :D)

> En C, on peut écrire un programme sans aucun retour à la ligne (mis à part les #include et #define)
Oui, enfin, il y a une utilité pratique indéniable aux retours à la ligne: ça marche mieux avec diff et patch, au delà de toute considération esthétique :)

> 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.
Ben justement... non, elle reste la même.
Ce qui est un peu le but, quand même. Je suis pas stupide à ce point, si changer la taille des tabulations brisait la présentation, ça ferait longtemps que je n'utiliserais plus les tabulations :p

> Or tu démontres que tu VEUX que le code soit bien indenté au caractère près et utiliser pour cela des espaces.
C'est un cas VRAIMENT spécial ou ni les espaces ni les tabulations ni le mélange des deux ne brisent la présentation. Le généraliser pour dire "les tabulations, sainul", ça manque un peu de rigueur mathématique ;)

> C'est pourtant exactement pour cette situation (pourtant très courante)
Heu... non, pas courante du tout. C'est la seule fois ou j'ai besoin de mélanger, et comme je l'ai dit, ça passe comme un charme (et oui, j'ai essayé dans différentes configurations)...

> Il fallait lire : « mon code sera lisible dans tout éditeur ÉTANT CONFIGURE EXACTEMENT COMME LE MIEN
Mais NON, NON et re-re-NON !!! (j'insiste)
le but est JUSTEMENT que quelle que soit la configuration de l'éditeur, le code source reste autant lisible en s'accordant aux gouts du lecteur ! Le but est justement de ne RIEN imposer comme style (taille de l'indentation, wrap ou pas wrap, wrap en début de ligne ou au même niveau que la ligne précédent ou à un niveau supérieur...). Avec la solution espace, ça passe effectivement partout, mais tu impose ton style au lecteur/contributeur. TOUS mes codes sources passent très bien partout (et je vais me répéter, mais j'ai essayé). Éventuellement, il arrive parfois que la configuration de l'éditeur m'insupporte (genre 8 espaces pour une tabulation, je déteste ça) quand je suis pas chez moi, mais c'est le pire qui puisse arriver.

Toutes, TOUTES les critiques "valides" que j'ai lues concernant les tabulations jusqu'ici proviennent d'éditeurs foireux (genre "oui, mais mon éditeur change les tabulations par 4 espaces en dur et du coup ça pollue les patchs"). Moi aussi je peux faire pareil: j'ai vu certains codes sources indentés à 3 espaces (parce que son auteur aime les espaces) où 8 espaces étaient remplacés par une tabulation (configuration foireuse), ce qui donnait un truc hideux du genre
SSSSSSif(foo)
TSbar();
(d'ailleurs, si mes souvenirs sont bons c'et le cas dans GNUstep - mais pas à 3 espaces - ce qui a été une raison suffisante pour que je m'arrête de plonger dans le code de GNUstep)
conclusion: les espaces, c'est de la merde en sac, si l'auteur avait utilisé des tabulations dès le début ça aurait fait chier personne
Mais comme j'aime pas être de mauvaise foi, je n'utiliserai pas ça comme un argument :p

J'ai l'impression que tu as répondu à mon message sans réellement prendre la peine de le comprendre...

> Pourquoi tu colles à la BSD la notion de partage et pas à la GPL ?
Bon sang, relis mon message sans tes oeillères de croisé !
Je t'ai donné un exemple précis! Grâce à la GPL, les partages entre *BSD et Linux se font difficilement et parfois avec une certaine tension (comme dans ce cas). OpenSolaris et Linux ne peuvent tout simplement pas le faire (sauf à passer par une licence intermédiaire commune genre... BSD. Mais seulement pour le code nouvellement écrit)
Je ne parle pas des échanges sur la LKML entre devs Linux et devs Linux, je parle de partage entre projets. Est-ce si dur à comprendre que à ce niveau, la GPL pose tellement de problème dès que les projets ont des licences distinctes, que, dans la pratique, la GPL l'interdit ? (pas dans le texte, mais c'est un effet de bord tout à fait indésirable... et inacceptable aux yeux de Théo)
Au lieu de bêtement troller, pourrais tu prendre la peine d'essayer de comprendre le point de vue de Théo et des BSDistes pour qui le partage et la coopération sont les choses les plus importantes ?

> Avec la BSD, je prend, je redistribue le binaire (avec des brevets si je veux, avec une "taxe" d'utilisation, etc)
En europe, ça va pas le faire
Ce n'est pas parce que les US ont des problèmes à la con que le reste du monde doit en subir les workaround/hacks douteux :p

> et je ne partage pas les sources.
Si c'est un logiciel libre genre openBSD à la base, tu peux les trouver sur internet. Où est le problème ? Si ce n'en est pas un, on se fout de toute manière de la licence (et, en ce qui me conerne, du binaire)

> La liberté en moins.
Bon, on va prendre un exemple moins choquant pour tes chastes oreilles :)
le "tout GPL" est une solution aussi acceptable au problème de l'incompatibilité des licences que la solution du "tout Gecko" au problème de l'incompatibilité entre le rendu des différents navigateurs (même en oubliant IE)
Ça passe mieux comme ça ?

> M'enfin, si tu t'en fous de la liberté, c'est normal que tu dis ça.
Théo est encore plus intransigeant que la plupart des devs/distributions Linux sur les blobs. Je te trouve plutôt gonflé d'essayer de venir faire la morale sur ce point... Ne t'en déplaise, OpenBSD EST ET RESTERA libre

Sans vouloir être méchant, à te lire, j'ai l'impression que tu as développé une paranoïa aigue envers le proprio, et que ça se ressent sur ton discernement. La prochaine fois que tu me réponds, s'il te plait, fais le en te plaçant du même point de vue que moi: dans un monde ou le proprio n'existe pas... (il existe, mais personnellement, je fais comme s'il n'existait pas). Dans le cas contraire, tu es assuré de répondre à côté de la plaque comme tu viens de le faire - et de monter encore plus dans l'escalade de l'incompréhension, ce qui serait dommage.
Après, bien sûr, d'un point de vue où tout se ramènerait à une sorte de guerre sainte "libre vs proprio", la GPL me semble la meilleure licence concevable. Mais ne t'en déplaise, c'est un point de vue rarement pris par les BSDistes et qui explique peut être certaines incompréhensions...

> Adobe produit Flash
Ben voilà, tu viens de trouver un avantage évident d'OpenBSD sur Linux: OpenBSD n'attire pas (encore ?) les mouches à merde, lui :D
---->[]

> Ça, c'est le meilleur moyen d'être sûr que ton code sera illisible partout ailleurs que dans ton éditeur.
Que mon code sera lisible dans tout éditeur sachant gérer les tabulations correctement.

> Si tu règle ta tabulation à 2, essayes par exemple
> $ cat ton-fichier.py
> $ a2ps ton-fichier.py
> ...
1. man sed
2. Le rendu dépend aussi de la police utilisée (au moins monospace ou pas). Tout le monde ne code pas dans un terminal ! A coté de ça, le "problème" des tabulations est vraiment mineur...

> 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) ? Le propos des tabulations est justement de coder sans se préocupper de la présentation visuelle et de laisser l'éditeur s'occuper de cette dernière selon les préférences de l'utilisateur...

> SSune ligne
> TTune autre ligne
Tu sais, si seules les tabulations sont autorisées c'est plus un problème :)
Mais sans aler si loin (je suis d'accord que ce serait exagéréà le problème n'est pas les tabulations mais le mix tabulations/espaces (et ça, tout le monde est d'accord pour dire que ça pue)

> TTif (une-condition-un-peu-longue &&
> TTTTTTune-autre-condition) {
cf. les 80 caractères.
Mais en aparté, c'est tout de même la seule situation ou je m'autorise le mix tab/espaces en Objective-C:

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

Mais à part cette situation, je fais tout en tabulations dès que j'en ai l'occasion sans rencontrer aucun problème...

> Ce qui m'énerve ici, c'est que souvent la GPL est critiqué comme ayant l'objectif de faire chier BSD ou autre.

Ce qui m'énerve ici c'est que souvent la BSD est critiquée comme ayant l'objectif de pouvoir être transformée en proprio.

Quand j'utilise une licence BSD, MIT, ISC ou Zlib ce n'est pas pour "tiens, demain je vais rendre mon programme de 100 lignes proprio et me faire plein de thunes en le vendant 200¤" ou "Microsoft pourrait être intéressé par ce hack de deux lignes...". Ce n'est qu'un effet de bord. Le but est que je puisse réutiliser du code externe sans trop me poser de questions ('fin, ya quelques licences à la con à éviter, genre (L)GPL...) et qu'on puisse utiliser mon code sans se poser trop de questions.

Le proprio, j'en ai *rien* à cirer. Qu'il "vole" mon code, c'est le dernier de mes soucis. Pour la GPL, le proprio est un "ennemi" dont il faut se "défendre". Pour moi, c'est un autre monde que me laisse totalement indifférent.

Ce qui me rend triste, c'est quand on voit que "grâce" à des licences sympathiques comme GPL et CDDL, OpenSolaris et Linux (ce n'est qu'un exemple parmis tant d'autres !) ne peuvent pas coopérer (ou difficilement)... ça me fait vraiment mal au coeur...

Certains développent du LL pour la liberté. D'autres pour le partage. Mais dans certains cas, ça semble malheureusement incompatible, d'où le troll qui en découle. Et comme la liberté (GPL) traite le partage (BSD) sur le même plan que le proprio (l'inverse n'étant que très rarement vrai), on comprend un peu mieux le ressentiment de certains comme Théo, tu ne crois pas ?

(le "tout GPL" étant une solution aussi acceptable que du "tout MSN" pour le problème de l'incompatibilité entre les divers réseaux de messagerie instantannée)

Hé bien avec le nouveau système, on peut faire des deux manières:
"Bonjour {prenom} votre age est {0}".format("42", prenom="monde")
Les argument numériques, c'est 'achement pratique quand t'en as deux ou trois. Au delà, c'est sur que par nom est pus lisible. À chaque cas son utilisation.

> La GPL se défend contre le proprio
Non, la GPL se défend contre:
* le proprio
* BSD, MIT, ISC, Zlib...
* CeCILL
* À peut près tout le reste du monde, en fait
* Et même de la GPL-(n-1) en bonus

> Oui, je gueulerais. Mais je ne vais pas dire que c'est du vole de code GPL !
Ben là.... pareil :p. Qui a parlé de vol ? (à part peut être Théo, mais il a l'habitude d'exagérer tout, c'est ce trait de caractère qui t'énverve ? dans ce cas, un conseil: inspire, et ça va passer :))

> Enfin, du code BSD n'est pas systématiquement utilisable par du code GPL. Du code BSD peut avoir des brevets, la GPL ne l'accèpte pas.
Il me semble que la GPL interdit qu'on distribue un prog si on a des bervets dessus (ou plutot, demande au distributeur de n'attaquer personne avec ces brevets).
Mais si le distributeur n'est pas la même personne qui a le brevet, aucun problème.

> Je n'ai pas dit ça, je ne sais pas d'où tu prends cette citation.
Désolé, c'était Zenitram dans un commentaire. Alzheimer, toussa...

> les BSDiste gueulent est pour le moins étrange
Les BSDistes ne gueulent pas parce que les libristes utilisent du code sans rien reverser (ce serait effectivement un comble), mais parce que les libristes utilisent du code sans rien reverser et ensuite vont faire l'apologie du partage et la morale à Apple parce qu'ils reversent pas assez... Enfin, ça, c'est mon point de vue sur la gueguerre GPL vs BSD en général...

Pour le futur, je sais pas, mais pour le moment, c'est pas encore ça...il suffit de regarder Lib/ dans les sources pour s'en convaincre.
Mais pour ton problème, il y a la PEP 328 [http://www.python.org/dev/peps/pep-0328/], disponible depuis Python 2.5 avec from __future__ import absolute_import et par défaut dans Python 2.7

Pour le point un, je pensais que sur linuxfr on pouvait encore faire un peu de sarcasme, d'ironie et d'exagération sans avoir besoin de l'expliciter outre mesure. Pardon, je le ferai plus. La prochaine fois, je ferai un joli post politiquement correct à prendre direct au premier degré sans avoir à réfléchir.

Pour le second point, on dirait que tu as lu mon post sans (chercher à ?) le comprendre... À moins que ton seul but soit de nourrir le troll ? Si c'est le cas, fais le de manière plus subtile, s'il te plait. Merci.

> La version GPL continuerait à vivre sa vie de son côté, c'est tout.
Certain, personne ne dirait "ouin, ce sont de sales capitalistes qui volent le travail des contributeurs". Et la marmotte...

Pour le raw_int, à la limite, tu as toujours ctypes.c_int :)

> pour l'indentation, je me demande si autoriser a la fois les espaces et les tabulations est une bonne idée et s'il n'aurait pas fallu rejeter les tabulations.
Pas d'accord. Le mélange des deux est une mauvaise idées, mais beaucoup indentent avec des tabulations, ce qui est moult pratique ! Il n'y a guère que quelques éditeurs dinosaures (je ne citerai pas de nom) qui font ch*er à mal gérer les tabulations.
Les tabulations ont l'ÉNORME avantage de faire plaisir à tout monde: certain préfèrent avoir une indentation à deux espaces (moi), d'autres à 4 espaces (beaucoup, parmis les pythnoeux), d'autres à 6 (j'en ai pas vu beaucoup, mais j'en ai vus), d'autres à 8 (beaucoup parmis les codeurs PHP). La solution pour mettre tout le monde d'accord est d'utiliser les tabulations et de laisser l'éditeur choisir par combien d'espaces représenter une tabulation. Avec les espaces, tu imposes ton style aux autres, c'est chiant au possible.
Sans compter que dans le cas de l'indentation par espaces, à moins d'ajouter des * vim: je sais pas quoi: * ou des *emacs: xxx* qui polluent le code, tu es obligé de changer la configuration de ton éditeur dès que tu contribues à un proet différent. C'est vraiment lourd. (encore que moi, je suis pas trp dérangé, scite detecte automatiquement le style utilisé)
Selon moi, c'est plutot l'indentation par espaces qui devrait gicler...

> Tu es en train de dire que le souligné _ est l'opérateur de concaténation des tuples?? Beurk!
Non.
Avant, tu écrivais def spam(a, (b, c)) et tu pouvais faire my_tuple = (4,2); spam(a, my_tuple). C'est à dire que le décompactage du tuple se faisait implicitement. Maintenant, tu dois le faire explicitement, mais tu aurais aussi pu faire
def spam(a, my_bc_tuple): b, c = my_bc_tuple
En fait, je connaissais mêmepas la syntaxe def spam(a, (b,c))

> l'abus de self n'est pas corrigé, quand tu lis du python, cest "def f(self, ...) def g(self, ...)": pénibles ces self partout.
C'est a un énorme point positif: ça évite les variables "magiques" et c'est après tout un argument comme un autre (self peut être passé à travers *args ou **kwargs par exemple). Ça évite les comportements plus que surprenants provenant du fait que ce soit un "machin spécial" (je n'ai jamais réussi à utiliser correctement "this" en JavaScript...)

Préface: j'utilise GPLeux parce que je connais pas de bon terme pour ça, pas pour dénigrer les fans de la GPL. Merci de retenir vos bêtes poilues en laisse

La différence fondamentale entre GPL et proprio, c'est que les GPLeux disent quand même en général "nous sommes le bien (tm), car nous sommes pour la coopération et le partage entre les projets et les individus". Malheureusement, pour ces mêmes gens, la coopération et le partage se font plutôt entre les projets GPL et les individus GPLeux - dès qu'on sort de la GPL pour se tourner vers BSD, ISC, MIT, Apache, Zlib, voire même LGPL, ladite coopération se fait de manière unidirectionnelle. Je pense que c'est ça qui reste en travers de la gorge de Théo et de bon nombre de BSDistes. Le proprio ne partage peut être pas, mais lui au moins ne prétend pas en avoir l'intention...

De plus, si demain Qt 4.3 ou MySQL 6.0 abandonnent la version GPL (ce qui est parfaitement légal et dans les règles !), je pense que pas mal de GPLeux gueuleront (ça c'est passé pour d'autres projets de plus petite envergure, et les GPLeux ont gueulés). Ben c'est exactement la même chose que ce coup de gueule de Théo... Effectivement, Trolltech^Wles devs linux en ont le droit, mais pour quelqu'un qui se prétend être pour le libre, le partage et la coopération, ça la fout quand même un peu mal (si je voulais exagérer le trait, je dirais publicité mensongère")

Pour finir, tu dis "ils n'ont pas à se plaindre qu'on respecte la licence à la lettre et non pas à l'esprit". Je me souviens d'un bon nombre de GPLeux qui ici avaient critiqué la "Tivoisation" comme étant contraire à "l'esprit" de la GPL... un poids, deux mesures ?

Mis à part qu'une seule application à la fois pouvait accéder au système de son (pas de dmix) et que t'avais toujours un serveur de son qui mobilisait la ressource sans l'utiliser (et bien entendu, l'application que tu voulais faire utiliser le son ne passait pas par ce serveur de son et restait donc désespérément muette). Si on excepte ce "petit détail", ça marchait, effectivement...

Bon, j'étais en train de faire ma news mais j'ai été trop lent, donc je vais copier-coller ici mon brouillon contenant moult éléments non précisés dans cette news (c'est, en gros, une traduction et une précision des nouveautés)

* Les "petits" changements

Les opérateurs <> (équivalent à !=) et `x` (équilavent à repr(x)) sont supprimés du langage.

Disparaissent également dict.has_key(), apply(), callable(), coerce(), execfile(), file(), reduce() et reload()

cPickle a été supprimé, utilisez pickle. Une version optimisée sera utilisée de manière transparente dans le futur.

raw_input() a été renommé en input(). input() doit donc être remplacé par eval(input()).

long a été renommé en int afin qu'il n'y ait plus qu'un type pour représenter les entiers. Bien qu'il s'appelle int, il se comporte comme le long de Python 2.x

.next() renommé en .__next__()

xrange() renommé en range()

string.letters renommé en string.ascii_letters (de même pour string.lowercase et string.uppercase)

1/2 retourne maintenant 0.5 (pour avoir 0, utilisez 1//2). Notez que ce comportement existe déjà depuis Python 2.2 en utilisant from __future__ import division

Les opérateurs de comparaison ne renvoient plus un résultat pseudo-aléatoire pour deux types incompatibles ; à la place, ils lèvent une exception TypeError.
__getslice__, __delslice__ et __setslice__ ont été supprimés. Les méthodes __getitem__, __delitem__ et __setitem__ sont appelés à la place avec un argument de type slice

exec et print deviennent des fonctions (et non plus des mots clefs). Cela signifie entre autres que que print ('a', 1) affichera "a 1" au lieu de "('a', 1)" et que print seul ne fera rien du tout (au lieu d'afficher une nouvelle ligne).

def spam(a, (b, c)) est maintenant invalide. À la place, utilisez def spam(a, b_c): b, c = b_c

0666 est maintenant une erreur syntaxique, la syntaxe correcte est 0o666. Apparition de 0b..., équivalent à int(..., 2).

La syntaxe des nombres variables d'arguments à été étendue au décompactage d'itérables. Par exemple:
a, *b = (1, 2, 3) donnera a = 1 et b = [2, 3] (b sera une liste)
*a, b = (1, 2, 3) donnera a = [1, 2] et b = 3

super() peut maintenant être invoqué sans arguments et choisira automatiquement la bonne classe. Avec arguments, il n'y a aucun changement.

Les décorateurs peuvent maintenant être appliqués aux classes.

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

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

map, filter et zip renvoient maintenant des itérateurs à la place de listes.

* Changement dans les fonctions à nombre variable d'arguments

Il est possible d'imposer que certains arguments soient passés par leur nom. Pour cela, il suffit de les placer après *args. De plus, le caractère * seul (sans nom) peut être utilisé pour indiquer qu'une fonction n'accepte pas de nombre variable d'arguments.
Comme un bon exemple vaut mieux qu'un long discours:

>>> def spam(*args, egg): print(len(args), egg)
>>> spam(4, 2)
Traceback (most recent call last):
File "", line 1, in
TypeError: spam() needs keyword-only argument egg
>>> spam(4, egg = 2)
1 2
>>> def spam(*, egg): print(egg)
>>> spam(4, egg=2)
Traceback (most recent call last):
File "", line 1, in
TypeError: spam() takes exactly 0 non-keyword positional arguments (1 given)
>>> spam(egg=2)
2

* Apparition de nonlocal
qui signifie qu'une variable est accessible à un niveau supérieur (mais pas au niveau global). Exemple:

>>> def spam():
... ... a = 2
... ... def egg():
... ... ... nonlocal a
... ... ... a = 5
... ... egg()
... ... print(a)
>>> spam()
5

(sans nonlocal, cela aurait affiché 2)

* str, unicode et bytes
unicode est maintenant le seul type "chaine de caractères" et a pris le nom de str. Le type bytes a fait son apparition ; il a pour vocation de remplacer str pour certaines opération d'I/O (par exemple, les fichiers binaires) ou les sockets. Ce sont deux types bien distincts qui ne peuvent être comparés (b"foo" == "foo" lèvera une exception TypeError) ni implicitement convertis (str(b"foo") échouera). La convertion doit se faire via str.encode() ou bytes.decode(). En pratique:
- Un fichier ouvert en mode texte (open('test', 'r')) travaillera sur des "str" dont l'encodage est défini à l'ouverture (par défaut, utf-8) via l'argument encoding (pour ouvrir "test" encodé en iso-8859-1, on utilisera open('test', encoding = 'iso-8859-1')).
- Un fichier ouvert en mode binaire (open('test', 'rb')) travaillera sur des "bytes".
- socket travaille avec des bytes
- cStringIO et stringIO sont remplacés par io.StringIO et io.BytesIO
- bytes ne peut pas être utilisé comme index d'un dictionnaire.


* Annotation de fonctions
On peut associer une valeur aux arguments d'une fonction et à une fonction, par exemple pour de la documentation (mais pas seulement, puisque n'importe quelle valeur Python peut être associée)

>>> def repeat(a: "This will be printed", n: "Times to repeat") -> "Nothing.": print(str(a) * n)
>>> print(repeat.__annotations__)
{'a': 'This will be printed', 'return': 'Nothing.', 'n': 'Times to repeat'}

* Les exceptions
Les exceptions doivent maintenant toutes dériver de BaseException (il n'est plus possible par exemple de faire raise "Panic !"). De plus, la syntaxe raise Exception, 42 a été supprimée (faisait doublon avec raise Exception(42)). Il est également possible d'enchainer les exceptions (pour par exemple notifier "Une exception IOError a été levée lors du traitement d'une exception MyError"). L'attribut message a été supprimé.

* .keys(), .values() et .items() revus
.keys(), .values() et .items() renvoient maintenant un objet qui référence ces éléments et ayant le même comportement qu'un set. Il est d'ailleurs garanti que set(a.values()) == a.values(). En pratique:
- for x in a.itervalues() s'écrit maintenant for x in a.values()
- a.values() s'écrit maintenant list(a.values())

Et comme c'est un commentaire et non une news, je peux donner mes réactions à chaud non vérifiées:
* Faire de print une fonction a beau être une bonne idée pour la cohérence du langage, c'est ch*ant au possible dans l'interpréteur :p
* L'introduction de bytes semble avec carrément cassé les modules officiels (chez moi, httplib ne marche plus). Je vais voir ça de plus près plus tard.
* J'applaudis de mes quatres pieds gauches la refonte du système d'exceptions
* J'ai pas encore vraiment testé, mais le nouveau mot clef "make" me semble vraiment puissant :). En plus il sera intégré dans Python 2.6 \o/
* Grâce à la nouvelle division, python fait maintenant office de super-calculatrice de poche
* Les identifieurs non-ascii, ça me semble une idée plus que douteuse, m'enfin...
* Les itérateurs ont le beau rôle. C'est une très bonne idée AMHA :)

Toutafé. Le caractère d'une personne est entièrement joué à l'heure de sa naissance, il suffit d'un planétarium pour s'en convaincre...

> au moins dans linux il y a qu'ALSA et quelques autre trucs qui sont merdiques
Toi, t'as pas connu les joies d'OSS :D