Moonz a écrit 3630 commentaires

> 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

Trop gros, passera pas, même pour un vendredi soir...

> D'un autre côté, c'est dans la partie de la norme qui est là pour compatibilité et qui est découragée.
Tu veux dire, "obsolète avant d'être sorti" ?
Damned, ils ont pompés sur Debian !

[-1]

Bon, je suis un peu fatigué donc je regarderai tout ça demain histoire de pas dire de connerie, mais je vais (honteusement) détourner ce journal pour poser une question: vous connaissez quelque chose pour faire du image hashing ? Jusque là, je n'ai guère trouvé que quelques thèses dont j'ai pas tout compris et http://users.ece.utexas.edu/~bevans/projects/hashing/index.h(...) qui est une toolbox matlab que je suis en train de très difficilement essayer de faire fonctionner avec octave... (si j'arrive à le faire fonctionner, promis, je vais essayer de porter le tout pour que ça utilise CImg ;))

En même temps, si vous saviez ce qu'il reste d'arno maintenant...
--->[]

> Petit jeu, met toi dans une position de "fidele" selon ton intérprêtation et dit nous en quoi tu serais limité dans tes agissements?
Un musulman non intégriste que je côtoie tous les jours ne peut pas manger des tartes flambées à volonté...
Et ça, c'est quelque chose que je n'arrive même pas à concevoir :)

ps: je suis le seul à lire tes ê comme des ^e ?

En lisant un journal parlant de RMS ? T'as le droit d'être dégueulasse, mais merci de ne pas l'étaler en public.

> d'ailleurs est-ce que qqu'un l'utilise, est-ce que c'est 100% fiable ?
Je l'utilise tous les jours, et c'est fiable. Les seuls trucs qui foirent, c'est les logiciels qui créent un socket unix dans ton ~/.quelque_chose genre Transmission. J'ai envoyé un patch pour ça (entre autre) il y a quelques jours. J'ai un peu galéré au début avec le .Xauthority, mais lire le README m'a donné la solution. Il faut juste se souvenir que LD_PRELOAD est supprimé par sudo et su.

L'univers est un vieux bout de code trainant au fin fond du disque dur cosmique :)

> pouvoir être contrôler
s/être//
Lapsus NON révélateur, vous aurez bien sûr corrigé vous même :p

Qui diable a dit ça ?
Tu me demandes les avantages, je te le répond: comme le LL. Puisqu'il y a besoin d'expliciter, ça dépend de la personne, mais les principales raisons sont (en vrac):
- pouvoir être contrôler le fonctionnement de l'outil: transparence, voire modification (être actif au lieu de simple utilisateur passif)
- contrôle total de ses données (publiques et privées)
- corrolaire des deux: pouvoir changer immédiatement de fournisseur si ce dernier commence à "péter un cable"
Et note que ça a aussi exactement les mêmes inconvénients que le LL: si le reste du monde préfère les machins flashy et l'effet mouton à tous ces avantages, il y a de grandes chances pour que tu te sente un peu seul... (bien sûr, c'est un peu moins vrai pour le LL aujourd'hui, mais pense aux temps où "vous devez posséder Microsoft (c) Intenet Explorer (tm) version 4 ou supéreure pour accéder à ce site" était le pain quotidien de beaucoup d'entre nous...)

À mon avis, la meilleure protection, c'est imposer que pour l'utilisateur les permissions éxecutable et writable soient mutuellement exclusives (sauf pour les dossiers, bien sur :p)
Ya moyen de faire ça avec SELinux ?
Après, il faut que les interpréteurs (python...) jouent le jeu...

Les même qu'utiliser Linux à la place de Windows, Firefox à la place d'IE ou OpenOffice à la place de MS Office ?

Apparament, c'est un remake de Phatlinux

> * Upstart (gros morceau ça)
Qui ne sert qu'à lancer les scripts init. Leur grosse promesse avait été de remplacer cron + inetd. On attend toujours. Si c'était juste pour remplacer init, initng était à avant et fait un peu moins overkill

> * CD unique live + install
PCLinuxOS et Mepis le faisaient bien avant...

Pareil ici, mais:
/tmp 19:04 gcc -ffloat-store test.c -o test && ./test
Prend 800.000000 * 0.750000 * 0.600000 = 360.000000 ( 360 ) = 360.000000 ( 360 ) %

Ça marche donc avec -ffloat-store qui est activé pour -O1 (ou supérieur) ou -Os. En fait, il n'y a que -O0 qui fout la merde :)

> qui m'a fait découvrir que state='' et state=0 c'est pareil pour mysql
On commence à comprendre pourquoi PHP et MySQL sont faits l'un pour l'autre :o)