gc a écrit 2109 commentaires

L'illustre inconnu a gagné une Ferrari en récompense ?

Vu qu'il accède au root... si.

Sauf que :

- il est quand même pas mal de confiance vu que tu l'autorises à être root il pourra donc faire tout et n'importe quoi avec, on part donc du fait qu'on lui fait confiance, mais qu'on ne veut pas donner le mdp pour des raisons de commodité (même mot de passe sur plusieurs machines, envie de savoir via les logs qui s'est connecté en root à quel moment..)

- le "vrai" admin a un accès physique à la machine donc si ce genre de chose arrive il récupèrera physiquement la machine (plus ou moins détruite par contre) et révoquera les droits de la personne

En règle générale il faut vraiment faire confiance pour permettre à quelqu'un de devenir root, peu importe la manière, et ma formulation était mal choisie.

félicitations vous venez de passer avec succès votre test d'entrée à la rédaction du Canard Enchaîné :)

J'en profite pour signaler que la redevance en Suisse est d'environ 300 euros par an (sans doute parce que diffuser tous les matches de l'euro, les grand prix de F1 et le tour de france, ça ne doit pas être donné), pour relativiser.

Et beaucoup les radios publiques, qui sont nombreuses, bien que leur qualité soit en nette baisse depuis la prise de pouvoir idéologique des néo-libéraux chez France Inter et consort (les "chroniques" de France Inter sont assez édifiantes).

Or, le seul moyen théorique (en admettant que les protections soient efficaces et qu'il n'ait pas fuité autrement) pour éviter la propagation des titres sur un réseau P2P, c'est que 100 % des CD soient protégés. Si on protège dans la moitié des pays c'est mal barré. La seule chose qu'on gène en protégeant dans la moitié des pays uniquement, c'est l'usage privé.

Ben non, le problème c'est que techniquement leur protection est merdique, ce qui donne :

- un CD inutilisable dans certains lecteurs (à choix, t'auras probablement une chance qu'il ne marche pas dans ta bagnole ou dans ton DVD de salon ou dans ton baladeur)

- un CD rippable par pas mal de lecteurs/graveurs (à mon grand étonnement, mon Plextor 708 rippe tout ce qui est protégé comme une fleur)

Donc au final, ça fait chier l'honnête consommateur et ça n'aide en rien à résoudre le problème.

Deux solutions, mais dans tous les cas tu dois lui donner un moyen de "devenir" root.

Simple mais... : si cet utilisateur est vraiment "de confiance" tu lui communiques le mot de passe root.

Compliqué mais... : si tu ne veux pas lui communiquer le mot de passe root, tu installes le package "su" puis tu configures /etc/sudoers pour qu'il puisse exécuter la commande "sudo su" avant de devenir root.

DRM/DRI c'est le nom de l'architecture noyau(DRM)/xfree(DRI) pour l'accélération matérielle à partir de XFree 4 ; sauf que Nvidia a fait autrement dans son coin avec ses drivers Linux, et que si tu souhaites les utiliser ça n'a a priori rien à voir avec toi, en gros ils ont refait un équivalent à DRM/DRI à leur sauce, à ma connaissance.. Suis la doc NVidia, tu devrais t'en tirer.

- tu viens dans le forum python vanter les merveilles de perl, en présentant un exemple de code, et tu mets au défi les lecteurs de ce forum de te proposer
un équivalent en python
- je te propose mon implémentation et te demande ce que tu en penses (cela répond-il au besoin ? Que dire de l'approche one-liner vs adoption sytématique de code objet et de documentation, a fortiori au sein d'un projet ? Lisibilité des deux implémentations ?)
- sans te prononcer sur les questions ci-dessus, ce qui était l'objet supposé, ou à prévoir, de ton troll, tu te lances dans une critique enflammée du seul langage python en avançant des points dont, après leur développement, je laisse aux autres lecteurs le soin de juger de la pertinence ; moi je fatigue un peu.

On a deux problèmes.

Le premier, c'est le fait que lorsqu'on entend si souvent "abandonnez Perl et utilisez Python", c'est dommage et ça saute surtout aux yeux dans la situation des one-liners. Dans l'exemple que je proposais tout en haut, on a un programme Perl qui s'écrit en quelques minutes alors que l'équivalent en Python demande plusieurs fois plus de temps (j'aurais pu m'abstenir du terme "chiant" pour ne pas heurter ta sensibilité, je m'en excuse). Je ne discute plus du problème de pérénité du code, comme je l'ai expliqué déjà plus haut.

Le deuxième, c'est lorsque tu me demandes "tu n'es pas tenté [par Python] ?" : à ce moment-là, je me fends d'une explication bien plus longue expliquant pourquoi, pour moi, non je ne suis pas tenté par Python - et bien sûr, ça va bien plus loin que l'écriture de one-liner, heureusement. J'écris la collection des "problèmes" que j'ai rencontrés en utilisant Python, et d'ailleurs certains n'en étaient pas, ce que je suis parfaitement disposé à reconnaître. Sur le "débat" très long qui s'en suit, je fatigue autant que toi et je vais donc laisser à l'hypothétique lecteur (faut pas rêver) le soin de se débrouiller avec tout ce qui a déjà été dit sans en rajouter.

- dans un tel contexte, tu inclus à tes critiques l'approche objet de python... mais mise en regard avec celle de perl (si tant est qu'il en existe une), tu retournes ta veste et tu dis que tu choisis Ruby, bien sûr quand le besoin s'en fait sentir... tu serais pas comme Dutronc, à retourner ta veste toujours au bon moment ?

Voir ci-dessus. Je n'ai jamais retourné ma veste, relis le contenu. Je n'ai jamais dit que Perl était supérieur à Python en objet, j'ai seulement dit que pour les one-liner Perl était (largement) supérieur à Python, et que pour les "vrais" programmes j'ai rencontrés quelques problèmes avec Python qui ne m'ont pas plu ; mon choix actuel pour les programmes pour lesquels on peut choisir un langage de script se portant sur Perl (car je le connais bien et qu'il est raisonnablement satisfaisant) et/ou Ruby (car il est bien plus élégant que Python à mon humble avis, et semble avoir moins de problèmes que Python).

Du coup, tu veux montrer / prouver / proposer quoi exactement ?

Moi aussi je fatigue de répéter toujours la même chose :)

Si on pouvait vraiment parler de sucre syntaxique à propos de int(string), alors string.int() serait possible ce qui n'est pas le cas, donc le sucre n'a pas grand chose à voir ici. int() est un builtin, point, et c'est une décision dont je ne vois aucun intérêt, mais tu vas peut-être pouvoir m'éclairer. Ce qui fait en partie la force d'un langage malgré ce que pensent beaucoup, c'est sa bilbiothèque standard. Python a bien joué, il possède une bibliothèque standard très étendue. Mais il faut aussi qu'elle soit de qualité ; et une des qualités c'est l'orthogonalité, la logique qu'elle montre. L'ensemble des opérations de base sur les chaînes doivent être disponibles en tant que méthode sur les instances de cette classe, ça me paraît peu discutable, quand même ?

Tout est objet dans Python, mais manque de bol pour une fonction fondamentale comme la longueur d'une chaine il faut écrire 4 underscores pour obtenir la fonction. Pourquoi, une méthode len() c'était trop simple ? Ah non __len__() c'est mieux, ça va amuser les programmeurs de tapper 4 underscores, et ça va faire des programmes très lisibles puisque la qualité de Python c'est de donner des programmes lisibles...

Quant à la surcharge d'opérateurs, étant donné que Perl se prête moyennement à l'objet... Mais j'ai déjà dit et répété que Perl suxait pour pas mal de points, et pour l'objet c'est clair que c'est une de mes critiques les plus importantes (relis mon dernier post plus haut, je n'ai jamais affirmé que Perl était la panacée pour les gros programmes, surtout ceux qui se prêtent particulièrement à l'objet). Si je veux faire un programme conséquent en objet, qui n'a pas besoin impératif de performance ou de vérifications fortes avant l'exécution, je choisis Ruby, bien sûr.

J'ai répondu aux quatre critiques avancées et j'ai montré qu'elles ne tenaient pas.
Ça n'était donc que ça qui te retenait de passer à python ? Parfait, bienvenue au club !

Euh, bof :) je consens que le problème sur l'appel du constructeur père était du à mon ignorance de Python ; sur les closures tu as au contraire montré toi-même qu'elles n'étaient pas dispo et qu'on obtenait un programme long et verbeux (je peux faire du C pour faire ça merci ;p) ; sur l'interpolation des chaînes tu as au contraire montré toi-même que ce n'était pas possible ; et enfin sur le manque d'"orthodoxie objet" sur la classe string, ta réponse est de t'émerveiller d'une méthode __len__() et d'un builtin int(), en disant que si on n'est pas content on peut écrire ces méthodes soi-même (je me demande l'utilité d'écrire des méthodes dans une bibliothèque de base si c'est pour ensuite proposer aux gens d'en écrire d'autres soi-même).

Je ne vois pas de différence avec ce que je disais, on se retrouve encore une fois à devoir regarder de gauche à droite à gauche pour savoir qu'est-ce qui renseigne quel élément du format...

Ç'aurait été tellement plus simple de pouvoir écrire :

print "Scoop : gc va bientot $foo pour $bar"

ou :

print "Scoop : gc va bientot #{foo} pour #{bar}"

ou encore, si Python avait pu bénéficier de plus de bonnes idées :

print "Scoop : gc va bientot %(foo) pour %(bar)"

Mais il semble que ce soit Perl ou Ruby qui trustent les idées qui simplifient la vie des programmeurs...

Scoop: gc va bientôt laisser tomber perl pour python...

C'est pas demain la veille :)

Sur ce point j'avais "trouvé" la façon d'appeler le constructeur père sur google : je blamerais donc tes amis pythoniens qui ont parlé de cette façon "fausse" (qui fonctionne tout en ne fonctionnant pas, ce qui est amusant) et ceux qui ont mis un pagerank suffisamment haut pour que je tombe dessus et qui donc pensaient que c'était une très bonne façon de faire. Mais l'essentiel est qu'effectivement, cette critique tombe.

Ben euh je pense que c'est long et verbeux :) tu me montres que tu ne peux pas faire de closure en python et que tu es donc obligé de définir une méthode pour ton callback, alors que le code très court se prêtait particulièrment bien à être défini par une fonction anonyme... rien de nouveau sous le soleil, et j'aurais plutôt tendance à dire que tu viens de prouver toi-même la validité de ce que je disais ?

On pourrait d'ailleurs au passage noter la verbosité de devoir écrire "self." tout le temps, un cas qui est traité élégamment en Ruby par l'utilisation de @ pour préfixer les identificateurs, mais on ouvrirait encore un autre thread...

CPU: P4-2.8 HT
Ram: 1024
3D: i865G
Res: 1280x1024
FPS: 1328
FPS p-e: 165

Je tiens à dire que dans mon expérience personnelle le "score" à glxgears n'indique pas grand chose : au bureau j'avais un celeron-400 avec une voodoo3 qui s'en tirait très bien à q3 alors que d'autres avaient des p3 avec i810 avec des performances très moyennes, pourtant elles m'explosaient au "score" glxgears.

C'est vrai quoi quand on voit que mon i865G (chipset intel sur carte mère, truc bas de gamme) explose ta GeForce4MX, sachant en plus que l'athlon 2500+ c'est une très bonne bête qui doit probablement rivaliser avec un p4-2.8...

PS : le correcteur orthographique ne connaît toujours pas 'linux' ....

T'as essayé gnu/linux ?

En attendant, bouge ton cul et finis ton bomberman ! :)

Bon, je me suis décidé à chercher ce "local variable reference before assignment" et j'ai trouvé que lorsqu'on affecte une variable dans une méthode, par défaut elle est locale, il faut donc spécifier "global variable" avant. Pour moi c'est encore une mauvaise surprises avec Python : la fonction qui est "return somme" accède bien à la variable globale somme, mais la fonction qui est "somme = 1" crée une nouvelle variable locale somme. Ce n'est pas logique... Si on a besoin de mettre global somme en tête d'une fonction pour manipuler la variable globale, il faut que l'on doive le faire dans les deux situations, pas une seule. Que penses-tu de ce problème ?

Donc, bref, j'ai écrit le bout de code que j'ai spécifié plus haut (tu me demandes de te proposer du code à écrire en Python mais tu ne l'as toujours pas écrit, tu le noteras), sans utiliser globals() grâce à ton "trick" de passer par des fonctions getter/setter :

liste = [ 1, 2, 3 ]
somme = 0
def getSomme():
    return somme
def setSomme(x):
    global somme
    somme = x
nouvelle_liste = map(lambda x, g=getSomme, s=setSomme : s(g()+x) or x*2, liste)

Bon, donc ok de cette manière on arrive à faire une closure, mais que d'efforts ! Et une fonction anonyme qui demande la définition de deux fonctions par variable extérieure à manipuler, hum...

Pour répondre à ta question sur l'utilité des closure : d'une part, quand tu l'as dans le langage que tu utilises (perl, ruby, ocaml par exemple) tu as plus tendance à l'utiliser, ça ne me semble pas choquant que tu aies l'impression de ne pas en avoir l'utilisation. Dans la même veine que le calcul de la somme ci-dessus, qui te demande en Python un deuxième parcours de la liste pour calculer la somme comme tu l'as écrit avec sum(liste), on peut en avoir besoin lorsqu'on a besoin de calculer quelque chose d'autre de non trivial (pour lequel il n'existe pas une fonction déjà définir comme sum) en même temps que le parcours de la liste, ou bien lorsque le parcours de cette liste est très coûteux, ou bien encore lorsqu'il provoque un effet de bord qui oblige à ne la parcourir qu'une seule fois. Un autre exemple courant est le branchement d'un callback sur un événement : typiquement dans gtk, par exemple avec le code suivant :

sub run_my_dialog() {
    my $results = 1;
    my $dialog = make_gtk_dialog();
    $dialog->button1()->signal_connect(clicked => sub { $results = 2 })
    $dialog->run();
    return $results;
}

La possibilité d'écrire une fonction anonyme qui soit une closure est ici particulièrement pratique pour "sauver" une valeur qui sera disponible lorsque le dialogue sera fermé. Sans closure, écrire cette fonction devient beaucoup plus lourd (tu peux l'écrire en Python ?).

Sinon, au sujet des expressions ternaires, je m'en mords les c*** de ne pas m'en être servi pour ma critique de Python :) c'est vrai que c'est dommage d'avoir oublié ça (comme il est dommage de ne pas avoir mis "variable++" en Python ou en Ruby d'ailleurs) même si on s'adapte aux petites erreurs de son langage favori.

Alors pour terminer ce thread trop long sur une note plus positiive : je suis bien sûr d'accord que chaque langage a ses défauts : en Perl, l'objet est mal branlé, les $/@/% pour les types de données sans possibilité de nester c'est chiant, les prototypes des fonctions qui n'en sont pas vraiment et la nécessité d'affecter à la main les paramètres des fonctions dans des variables locales c'est naze, et j'en passe probablement beaucoup ; en Python on a quelques soucis comme déjà énumérés ; et en Ruby il y a aussi son lot de frustration, mais on ne va pas commencer avec ça. Ce thread a beaucoup dérivé lorsque tu m'as demandé si j'étais pas "tenté" par Python, mais je voudrais repréciser mon propos initial : je voulais montrer que pour les petits one-liner, les programmes très compacts et "jetables", Python n'est pas adapté ; je pense que les fonctionnalités de Python en font un langage adapté pour les "vrais" programmes plutôt que les one-liner (ce que tu disais toi-même plus haut il me semble) (même si je ne vois que des avantages à Ruby sur Python pour faire ce genre de programmes), je voulais donc dire que pour le genre de tâche que j'exposais au début, Python ne me semble pas adapté, et même si l'on aime Python pour plein de raisons, peut-être est-ce judicieux d'utiliser quelque chose d'autre - ce que disait un des commentaires du début, même si utiliser sed quand on a perl sous la main me semble relever du masochisme :).

ouf :)

c'est pas génial mais c'est vrai que c'est mieux que rien (j'en apprends sur Python en ce moment moi c'est fou) - et pour info, je fais du java toute la journée et on utilise "J'ai " + age + " ans" (grâce aux méthodes de conversion de type nommées implicitement, une bonne idée qu'on trouve dans ruby aussi avec to_s to_i etc) et je trouve déjà ça lourd et chiant à tapper...

Euh ton code me donne deux fois [5, 5, 5] (Python 2.3.4) - puisque le lambda capture encore une fois la valeur de la fonction à sa création (s1 donc) et ton affectation de s2 à somme n'y change donc rien (tu as testé ton code ?). Mais ça me semble une bonne idée que je vais continuer :

liste = [ 1, 2, 3 ]
somme = 5
def s1(): return somme
l = lambda x, s=s1 : s()
print map(l, liste)
somme = 7
print map(l, liste)

Qui me donne bien [5, 5, 5] et [7, 7, 7], puisque la valeur capturée est la fonction s1 qui elle capture bien la variable somme en tant que telle et non sa valeur, une fois appelée elle saura rendre la vraie valeur de somme.

Il est donc possible de "simuler" une closure en Python en définissant un getter pour la variable que l'on veut capturer - je ne m'en étais pas douté, cette discussion aura au moins l'avantage de me révéler ça :). J'aurais supposé qu'en changeant la valeur de somme depuis la fonction s1 j'aurais même pu réaliser le fameux truc qui nous occupe (changer une variable locale/globale depuis un lambda sans avoir recours à global()) mais Python me dit "local variable 'somme' referenced before assignment". Il veut bien que j'affecte x à somme mais pas que j'ajoute x à somme, ça doit être un truc commun en Python mais là je vois pas, tu sauras sûrement pourquoi.

Bon, c'est déjà ça - mais si on souhaite simuler des closure comme cela en Python on ne peut pas franchement dire que ce soit d'une élégance folle, tu ne trouves pas ? On se retrouve quand même avec trois "noms" différents pour une même variable : son vrai nom, le nom de son wrapper, et son nom affecté en paramètre du lambda...

Oui, la façon d'accéder à la valeur de la variable au moment de la création du lambda est de le nommer comme paramètre du lambda. Mais tu ne peux pas changer cette variable, car tu n'en as pas la "référence" mais bien la valeur. Puisque tu me demandes de te proposer d'écrire du code : reprends juste mon exemple avec le calcul de la somme dans le lambda. Essaie de nommer "somme" comme paramètre du lambda, et de lui additioner x, avant de rendre x*2 comme résultat du lambda. Tu ne pourras pas le faire, à ma connaissance.

Je réitère : ce n'est certes pas une closure, avec capture de la variable, mais bien une capture de la valeur au moment de la création du lambda ce qui n'est pas la même chose, et en tous cas bien moins intéressant :

liste = [ 1, 2, 3 ]
somme = 5
l = lambda x, somme=somme : somme
print map(l, liste)
somme = 7
print map(l, liste)

donnera :

[5, 5, 5]
[5, 5, 5]

alors qu'une closure aurait pu permettre d'obtenir la nouvelle valeur de somme dans le deuxième appel

Rah mais tu vois bien que c'est pas une fonction anonyme nomdidjiou ! Tu es obligé de la nommer, la déclarer, les fonctions sont des first-class value comme en C ou en Java heureusement on n'est pas en Pascal quand même ; mais tu ne peux pas spécifier ta fonction anonymement dans le map.

Non, pas comme ça.

>>> a = 4
>>> b = "meuh"
>>> print b + a
Traceback (most recent call last):
File "", line 1, in ?
TypeError: cannot concatenate 'str' and 'int' objects

Et puis j'aime pas les $ (et autres) devant les noms de variables :)

Ouais ça ca sux. Sans compter le fait que les @tableaux et les %hash ne sont pas "nestables" en l'état, il faut utiliser des références. Ça alourdit beaucoup la compréhension et ça complexifie le langage. Ils disent qu'ils vont changer tout ça dans perl6.

Sinon pour les quelques défauts de Python que tu décris, c'est intéressant mais certains sont des cas très spécifiques, non ? ;)

C'est des cas dans lesquels je me suis heurté à l'utilisation, donc... je ne pense pas avoir spécialement une utilisation spécifique. Ce sont des problèmes qui m'ont beaucoup gêné, et qui n'existe pas ni en Perl ni en Ruby.

texte".__len__()

Ah, je ne connaissais pas. C'est mieux que rien. Mais bon si on veut critiquer la lisibilité d'un programme Perl et dire que Python c'est lisible, ce n'est pas avec des méthode avec deux _ de chaque côté qu'on va y arriver :)

Quant au print avec multiples arguments, il est peu utilisable en l'état car il ajoute un espace entre chaque élément obligatoirement (si tu connais un moyen de ne pas avoir ça...).

Le problème c'est le fait que le lambda n'est pas capable de capturer l'environnement (l'extérieur), on ne peut donc pas créer de closure[1] et c'est pour cela que ces fonctions anonymes sont castrées. Dans mon exemple effectivement c'est peu gênant, et tu t'en sors bien :) mais dans de nombreuses situations c'est la merde : par exemple quand tu veux brancher un callback, dans le callback typiquement tu voudras modifier la valeur d'une variable à l'extérieur du lambda, en Python tu es obligé d'utiliser globals().get() et globals().update() comme j'ai montré, ce qui donne un lambda très lourd. Sans compter que dans le cas d'une variable locale à la méthode dans laquelle le lambda est exécuté, a priori on ne peut tout simplement pas y accéder.

[1] http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=closure(...)