bobert a écrit 604 commentaires

...et ta mère tu nous la présente quand ?

Hein ? Non, rien moumoune, je poste juste un truc sur linuxfr...

;-))

hardy $ oerr ORA_Preface.doc

Rhaa p....n, qu'est-ce que je fous, moi ?!?

Sauf que dans Blade Runner l'effet était voulu. cf. par exemple l'analyse de Philippe Lemieux [1], dont voici un court extrait mais qu'on lira en entier avec le plus grand profit:

Mais l'étude de la vision va plus loin. Deckard, un être humain froid ,qui a perdu tout sens de la vie, des émotions, ne voit pas l'importance de vivre chaque jour pleinement. Il n'est qu'un témoin : "All I could do was watch him die". Paradoxalement, les réplicants sont avares de sensations et de vie puisqu'ils en manquent et chaque seconde compte. Les étiquettes "humain" et "être artificiel" sont ici interchangeables. L'omniprésence de photographies qui renvoient aux divers souvenirs personnels des personnage, leurs passés, est aussi un élément lié à la vision. La photographie joue ici le rôle d'aide mémoire, d'objet qui permet de "voir dans la passé". C'est d'ailleurs en étudiant une photographie de Leon que Deckard retrouve Zora dans le film. Finalement, le fameux test Voight-Kamff qui permet d'identifier un réplicant mesure la dilatation de la pupille en tant qu'indice de l'état émotionnel du sujet. Deckard ne subit jamais ce test lui-même...

[1] http://www3.sympatico.ca/philippe.lemieux2/blader.htm(...)

Bon je voudrais pas te foutre le moral à sac, mais a priori c'est pas encore gagné.

Les dernières nouvelles sur linux.kernel sont ici (http://groups.google.com/groups?selm=2iJx4-3Tu-9%40gated-at.bofh.it(...)), elles datent d'hier.

Un gars fait état de ses essais avec le même disque que le tien. Avec le noyau 2.6.7-cko1 il arrive à le faire tourner, mais avec des corruptions de données aléatoires, à un taux de ~ 1 byte erroné /10 Gb de données lues.
Le noyau le plus récent est le 2.6.8rc1, le gars dit l'avoir aussi testé mais sans succès car trop instable (perso je le trouve très bien celui-là)

Donc si tu peux vivre avec un tel taux d'erreur, et si ça peut te dépanner, je veux bien te graver des isos de la Mandrake Cooker avec le dernier paquetage du 2.6.7, pas de problème... m'enfin à ta place, j'attendrais un peu...
Et en attendant, surveille la mailing-list, voir quelles seront les réponses au susdit message. Si tu fatigues avec l'Anglais dis-le moi et je te traduirai l'essentiel.

C'est quand même pénibe toutes ces failles ! Si ça continue faudra que ça cesse !!

Coca-cola c'est le logo rouge, et Mandrake c'est l'étoile jaune, pourquoi vouloir à tout prix changer ça ? Ou tu en fais une question de principe (ce que je pourrais comprendre) ?

Moi en tout cas, ça me choque pas. Je dirais même, que si 50% des Français pouvaient se décider pour l'achat d'un ordi plutôt qu'un autre "parce qu'il y a l'étoile jaune dessus", ben franchement je me sentirais vachement mieux...

... parce que je pense pas avoir le temps de développer tout ça (désolé).

De mon côté je distingue surtout 2 catégories d'élèves, sans tenir compte de l'âge:

- les gens qui ne se serviront de la programmation que pour automatiser leurs tâches personnelles, ou peut-être automatiser quelques tâches au sein d'un groupe de travail.

Pour ceux-là l'approche que j'adopte c'est: langage de haut niveau + emploi systématique de la programmation objet + mini-rudiments de l'UML (du niveau "avant d'écrire une classe, dessine simplement un rectangle sur une feuille de papier ; en haut, écris le nom de la classe, etc..."). Python répond bien au besoin. Pour l'approche objet, ça roule tout seul si on va doucement.

- les gens qui à un moment ou à un autre, auront la tâche de développer tout ou partie d'un logiciel. Par exemple des étudiants en IUT telecom & reseau, à qui j'enseigne en ce moment le C et le Java. Ils ont l'impression, et beaucoup de gens avec eux, qu'apprendre le C (comprendre, faire de la programmation de "bas niveau" -- c'est comme ça qu'on l'appelle ! Il y a 25 ans le C était un langage de haut niveau...) est ringard et inutile, la "vraie" programmation c'est de la POO en C++ ou à la rigueur en Java.

Je ne souscris bien sûr pas à cette idée ; mon approche est plutôt celle (désolé d'être rapide) de "Back to basics" de Joel Spolsky (http://www.joelonsoftware.com/articles/fog0000000319.html(...))

Par contre je ne sais pas s'il vaut mieux passer d'abord par le C, l'allocation dynamique ou statique de mémoire, les pointeurs, etc, avant de passer à un langage de plus haut niveau, ou l'inverse. Pas évident.

Prends d'abord le temps de rationaliser tes besoins, la partition de ton disque en dépend directement.

1. Quelles étaient tes besoins sous Windows ?
==========================

- j'imagine au moins internet, e-mails, un peu de bureautique
- jeux ?
- autres ?

2. Qu'est-ce que tu peux faire migrer sous Linux ?
=============================

D'une manière générale, il faut t'imaginer que tout peut se faire sous Linux, sauf si tu es joueur de jeux spécifiques pour la plate-forme de Microsoft, et si tu as des besoins très spécifiques dans certains domaines. Pour ces besoins spécifiques il faut chercher / demander au cas par cas si l'équivalent existe sous Linux.

Mais pour un usage personnel classique, sans tenir compte des jeux, *tout* ce que tu faisais sous Windows peut être aussi bien fait sous Linux.

Ça implique:
- de récolter tes informations personnelles (e-mails, documents de bureautique, donnnées d'autres applications) en vue de ta migration. Ça peut consister à graver toutes ces données sur CD (du même coup du fais une sauvegarde, ce qui est + que conseillé) ou bien de les placer sur une partie de ton disque dur
- que tu peux soustraire à l'espace réservé à Windows l'espace auparavant nécessaire pour tous ces besoins. Exemple: tu utilisais Microsoft Office sous Windows qui te prenait (peut-être) 700 Mo. Tu peux les yeux fermés mettre de côté tout tes documents Office et désinstaller Office --> l'espace réservé à Windows perd tout de suite 700 Mo



N'hésite pas à poser des questions sur ce qu'il est possible de migrer sous Linux et comment le faire (import/conversion de tes données)

Je renchéris !
Si tu débutes ça n'a pas beaucoup de sens de compiler toi-même les applications dont tu as besoin, ça a déjà été fait à ta place.

1. configure correctement tes sources de paquetages en suivant les directives (en anglais malheureusement) de cette page http://plf.zarb.org/~nanardon/(...)
2. ouvre un terminal
3. change-toi en superutilisateur avec la commande su
4. tape "urpmi gphoto2 mldonkey"

C'est tout !
La gestion & la richesse des paquetages de la Mandrake est une de ses plus grandes forces ; c'est impensable de s'en passer !

... de tomber comme un cheveu sur la soupe :-( mais j'ai fait le chemin exactement inverse... je m'explique:

- tes fichiers, ou documents, appelons-les comme on veut, renferment de l'information qui t'intéresse
- le type d'un document ne préjuge pas de l'information qu'il contient. Je veux dire qu'une information donnée peut aussi bien se trouver dans un document toto.txt que dans un document toto.sxw, ou même, parce que tu l'aurais scanné, dans un fichier toto.jpg, ok ?
- Je redis juste la même chose d'une autre manière: ranger des documents suivant leur type mime, c'est faire une partition de l'ensemble de tes documents (découper ta liste de documents en morceaux) qui sera inutile, ou inefficace disons, pour la recherche de tes informations dans ces documents
- D'autre part, si j'ai bien compris, ton outil aide à la création d'une structure de répertoires / sous-répertoires / noms de fichiers. Cette structure-là, ce sont des méta-informations (des informations associées à tes documents), d'accord ? Sous forme de répertoires et de noms de fichiers, tu va stocker en gros 2 types de méta-informations:
* des informations sur le document (titre, auteurs, date de création / publication), qu'on pourrait qualifier de bibliographiques
* des informations permettant le classement de ce document, par exemple une ou des catégories, ou concepts, auxquels se rapportent le document

Or, autant les informations bibliographiques sont spécifiques à un document donné, autant les informations de classement sont communes à tous tes documents. Mettons par exemple que tu aies pris l'habitude de classer tes bookmarks dans un arbre de catégories comme

loisirs
..........musique
..........littérature

informatique
..........programmation
..........logiciels libres

juste pour prendre un exemple. Eh bien il te faut aussi maintenir une telle structure pour tes e-mails, tes bookmarks, tes documents texte, tes images, tes notes, etc...

Donc, quand bien même ton outil aiderait à créer de telles structures de classement la première fois, tôt ou tard tu te retrouves à maintenir à la main des structures de classement différentes (pour chaque type de documents) alors que tous ces documents renferment des informations de même nature...

Pas glop tout ça. Enfin de mon point de vue.
Donc je t'invite à considérer la démarche exactement opposée:

- tu repères chacun de tes documents par un identifiant unique. Le fichier associé est nommé à partir de cet identifiant.
- gère et stocke tes méta-informations en-dehors du système de fichiers. Peu importe où et comment: dans une feuille de calcul, ou mieux, dans une base de données (SQLite par exemple... j'aime bien SQLite, je t'en ai déjà parlé ?!?)
- comme tu peux identifier chacun de tes documents à partir de son simple identifiant, plus besoin de structure de répertoires: fous-les tous dans un unique répertoire

Voilà l'idée, en tout cas la démarche qui me réussit le mieux personnellement. Réfléchis-y un peu, les avantages ne sont peut-être pas évident au premier abord...

Tu as bien décrit l'installation de cette distribution.
Mais quels en sont les avantages spécifiques ?

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...

C'est clair qu'avec ce genre de coupage de cheveu en quatre on fait vachement avancer le débat. Après cette longue discussion on en revient donc à l'essentiel selon toi, le nombre de caractères à taper ?
C'est marrant parce si je reprends ton argument ça doit bien te faire chier de taper des trucs comme ça en perl, non (pris au hasard dans /usr/lib/perl5) ?

$self->{structure} = new Text::BibTeX::Structure ($structure, @options);

Elle est où, la concision et la lisibilité, là ? Allo ??


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.

Alors, résumons-nous.
- 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.
- 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 ?

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

Je ne vois pas de différence avec ce que je disais

Là je dis chapeau... être d'aussi mauvaise foi avec autant d'assurance, je m'incline, c'est bien toi le meilleur !

Tu disais donc, et je te laisse la paternité d'une telle affirmation, qu'avec

"Scoop: gc va bientôt laisser tomber %(langageIllisible)s pour %(langageCool)s ..."

il n'y a pas d'interpolation, et ça ne se lit pas de gauche à droite...

Sans commentaire !

Ben euh je pense que c'est long et verbeux :)

Arrête, tu es de mauvaise foi, on repart pas sur des bonnes bases là...

Long ? Tu compares quoi avec quoi ?
Tu n'as écrit qu'une procédure ; j'ai écrit un programme complet !!
Ecrire l'équivalent en perl serait *aussi* long !!

tu me montres que tu ne peux pas faire de closure en python

Non, je te montre que *rien* ne justifie que tu parles d' énorme problème de Python, qui t'empêche d'écrire du code fonctionnel. Tu peux me dire à la limite que python te donne des boutons, que tu le supportes pas, mais dans la pratique, je t'ai demandé des cas concrets, où tu te sentirais "bloqué", pour te montrer le code équivalent en python pour répondre au besoin.

Reprenons:

1. tu as commencé par affirmer que, quand tu veux écrire en perl,

@nouvelle_liste = map { $somme += $_; 2*$_ } @liste

en python selon toi on doit définir une fonction, ou bien utiliser un for... in.... Au départ de l'action c'était ça ton problème super bloquant.

J'y ai répondu par le code équivalent en python:

nouvelle_liste = map(lambda x:2*x,liste)
somme = sum(nouvelle_liste)

2. tu as ensuite affirmé (sans convenir que ta situation concrète n°1 n'était plus bloquante du coup) que le problème c'est le fait que le lambda n'est pas capable de capturer l'environnement (l'extérieur)

Je t'ai montré que c'était faux:

map(lambda fonctionAnonyme:x,g=objetGlobalQuelconque : <corps de la fonction anonyme>, liste)

3. tu t'es ensuite arquebouté sur le manque de fermeture des formes fonctionnelles en python, que c'en était tellement bloquant que rien que d'y penser tu te sentais mal.

De deux choses l'une:
- soit tu en fais une question de principe ("je refuse de coder quoi que ce soit dans un langage qui n'offre pas de formes fonctionnelle avec fermeture") mais bizarrement tu as l'air de coder en java dans ta journée sans que ça te pose problème...
- soit c'est effectivement indispensablissime, et tu as des cas concrets de code en perl mettant en oeuvre une telle fonctionnalité, et dont l'équivalent en python te semble irréalisable

Nous en sommes donc là, sachant que dans de tels cas hypothétiques, où je bloquerais sur un équivalent en python, nous avons déjà convenu tous les deux dans l'intervalle qu'on pouvait toujours simuler la fermeture en python, et de façon plutôt plutôt élégante, cf ma deuxième proposition d'un tel code.

Tu m'as proposé une routine perl, et j'ai mis en oeuvre son équivalent en python dans un programme complet pour que tu puisses le tester : tu as le beurre, l'argent du beurre et la crémière, petit veinard...

En attendant, j'attends toujours le code perl qui montre le côté "bloquant" de la chose, ou bien cette discussion est close.

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...

??? Je ne définis rien du tout, et j'ai bien associé mon callback à une fonction anonyme. Le code incriminé est

dialog.rButton.connect('clicked',
lambda x,d=dialog: setattr(d,'result',2) & d.quit())

J'ai souligné le lambda, il était peut-être pas assez visible ?

On pourrait d'ailleurs au passage noter la verbosité de devoir écrire "self."

Mais oui, bien sûr !
Écris-moi donc l'équivalent de ce programme en perl, afin qu'on puisse noter la verbosité de devoir écrire $,@,%,->,& à tout bout de champ...
Sérieusement, s'il te reste plus que ça comme argument...

Je réponds ici à la quatrième et dernière critique de python par gc ci-dessus (http://linuxfr.org/comments/444523.html#444523(...))


On fait la publicité de Python comme langage objet. Mais pourquoi n'ont-ils pas fait les choses jusqu'au bout ?


Là, c'est quand même le ponpon ! Tu dis préférer perl à python, et dans le même temps tu critiques python en tant que langage objet... chapeau, faut oser !

Notons que je n'affirme pas que Perl est mieux là-dessus, Perl est une catastrophe pour l'objet

encore heureux... en python tout est objet ; en perl, objectivement je sais même pas si on peut dire qu'on puisse faire de quelque chose un objet. Sérieusement, la POO en perl est une expérience cauchemardesque que je préfère oublier. C'est dommage, c'est même un vrai gâchis, perl aurait pu être un super langage. Pour reprendre les mots de Larry Wall, perl est ce que la communauté en a voulu...

C'est objet mais pour avoir la longueur d'une chaîne, là où Ruby a fait le boulot correctement (chaine.length) en Python c'est len(chaine).


s="En python aussi, gc..."
print s.__len__()
22

Conversion d'une chaine vers un entier ? En Ruby je fais chaine.to_i en Python rebelote je dois faire int(chaine).


int est une fonction fabrique (design pattern : factory): elle crée un objet de classe int... je vois pas plus objet comme approche.

Par ailleurs je sais que tu sais (et tu le sais...) qu'il n'y a aucune différence fondamentale entre les deux formes f(a) et a.f(), c'est juste du sucre syntaxique, comme savent si bien dire les perliens.

Enfin, je me répète, mais le plus important est bien qu'en python, tout soit objet. Si la syntaxe par défaut ne te plaît pas, tu peux toujours ajouter les méthodes de ton choix aux classes natives afin de pouvoir écrire "128".to_i

Donc tes arguments avancés sur ce point ne tiennent pas.
J'invalide le point n°4.

Au passage, je n'imagine pas me passer de surcharge d'opérateurs, simplissime à mettre en oeuvre en python. Comment peux-tu survivre en perl sans ça ?


Conclusion

Et voilà ma conclusion sur Python, je disais que l'absence de fonctionnel l'alimenterait ; les points ci-dessus aussi.


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 !

Je réponds ici à la critique n°3 de python par gc, qui s'avère sans fondement.

Il n'y a pas d'interpolation dans les chaînes de caractères. Quelque chose de si pratique disponible dans tellement de langages de script (même Tcl !) et qui n'existe pas en Python, je trouve ça vraiment très dommage. On pourra me dire que ça rend le programme plus lisible, mais au contraire, devoir passer "de droite à gauche" comme on le fait dans un format en C ne rend que le programme moins lisible. C'est un détail mais c'est prodigieusement agaçant quand on programme avec Python.

ahem...

print "Scoop: gc va bientôt laisser tomber %(langageIllisible)s pour %(langageCool)s ..." % {'langageIllisible':'perl', 'langageCool':'python'}

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

Je réponds ici à l'une des critiques de python par gc (voir plus haut), que j'espère toujours convaincre de laisser tomber ses one-liners à 2 balles en perl pour passer à python ;)

message d'erreur totalement cryptique

Si tu écris cela :

class Foo:
    def __init__(self):
        print "Foo"
 
class Bar(Foo):
    def __init__(self):
        super(Bar, self).__init__()
        print "Bar"
 
b = Bar()

Tu te prends comme message d'erreur :

File "foo.py", line 7, in __init__ super(Bar, self).__init__() TypeError: super() argument 1 must be type, not classobj

Read The Fine Manual

La syntaxe par défaut pour appeler le constructeur de la classe parente est la suivante:

class Foo:
    def __init__(self):
        print "Foo"
 
class Bar(Foo):
    def __init__(self):
        Foo.__init__(self)
        print "Bar"

Ce qui invalide ta critique n°2.

Je reprends ici le thread plus haut qui devenait ingérable...

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 ?).

Voilà un exemple qui n'est pas une transcription littérale du code perl, mais qui je pense reste dans le même esprit ; teste-le et dis-moi ce que tu en penses:

#!/usr/bin/env python

import gtk
        
class EntryDialog(gtk.Dialog):
    def __init__(self,message="",defaultResult=1):
        gtk.Dialog.__init__(self)
        self.result = defaultResult
        self.set_modal(gtk.TRUE)
        self.entry = gtk.Entry()
        self.entry.set_text(str(self.result))
        self.action_area.pack_start(self.entry)
        self.entry.show()
        self.entry.grab_focus()
        self.button = gtk.Button("OK")
        self.button.connect("clicked", self.click)
        self.action_area.pack_start(self.button)
        self.button.show()
        self.rButton = gtk.Button("Recommended Value")
        self.action_area.pack_start(self.rButton)
        self.rButton.show()
    def quit(self, w=None, event=None):
        self.hide()
        self.destroy()
        gtk.mainquit()
    def click(self, button):
        self.result = self.entry.get_text()
        self.quit()
    
def runMyDialog():
    dialog = EntryDialog()
    dialog.rButton.connect('clicked',
        lambda x,d=dialog: setattr(d,'result',2) & d.quit())
    dialog.run()
    print "result=%s" % dialog.result

if __name__=="__main__":
    runMyDialog()

Merci pour ta réponse précise.

Le mieux quand il y a un probleme est de poser la question à celui qui connait la réponse avant de poster ce type de news.

Il s'agit simplement d'un journal, je n'ai pas cherché à rameuter la France entière

Voter sur bugzilla et poster des messages sur la liste Cooker est contre-productif.

Je n'ai moi-même posté à ce jour aucun message relatif à cette histoire sur la liste Cooker.

Si tu regardes bien il y a ni annonce officielle sur le site de la FSF ni sur celui de Mandrakesoft.
[...]
Je serais très heureux que tu mettes la même énergie à faire que Mandrakesoft respecte une promesse non faite sur des actions en direction des entreprises et hommes politiques.


Il se trouve que je mets une partie de mon énergie à faire des rapports de bugs sur http://qa.mandrakesoft.com(...) . J'ai eu la surprise de découvrir un rapport qui relatait l'histoire que j'ai retranscrite ici, étant moi aussi sensible à ces questions.

Ledit rapport a été créé le 01/03/2003 et assigné à Frédéric Lepied de Mandrakesoft. Les précisions que tu apportes ici, 16 mois plus tard, n'y figurent pas.

Comment et pourquoi aurais-je pu mettre en doute la véracité des informations contenues dans ce rapport, puisqu'il était hébergé sur un serveur de Mandrakesoft, assigné à une personne de Mandrakesoft, et laissé en l'état depuis le jour de sa création ?

Le débat est donc clos ici, mais je te suggère d'apporter les mêmes informations directement dans le rapport lui-même (http://qa.mandrakesoft.com/show_bug.cgi?id=2564(...))

Le plus tôt eût été le mieux...

Euh [...] (tu as testé ton code ?)

Nope... damned, tu m'as eu ! Mais l'idée y était.
Autre façon, plus utile car plus susceptible de coller à du code réel en python il me semble:

class C1:
....val=5

class C2:
....val=7

liste = [ 1, 2, 3 ]
a=C1
l = lambda x : a.val
print map(l, liste)
a=C2
print map(l, liste)

Et celui-là je l'ai testé ;)

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 :)

À la bonne heure...

on ne peut pas franchement dire que ce soit d'une élégance folle, tu ne trouves pas ?

Le code ci-dessus est plus propre ; m'enfin autant les formes fonctionnelles c'est du quotidien et c'est indispensable, autant la fermeture ça m'a encore jamais manqué ; j'imagine que tu dois pas en avoir un besoin cruel tous les jours, donc pour l'occasion tu peux bien accepter d'avoir ponctuellement du code qui ait pas une forme idéale.

Par exemple ce qui me manque pas mal c'est l'opérateur conditionnel ternaire (condition)?xx:yy. Tant pis, je fais sans, et ça n'est certainement pas son absence qui me fera dire de python comme toi "un bon langage pour mauvais programmeur". Ça n'est pas faux, d'ailleurs, c'est juste aussi un bon langage pour bon programmeur ;)

Si vraiment y'a que ça qui te bloque...

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

donne:

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

Tu sais pertinemment à quel moment se fait l'évaluation en python. Fais un déréférencement quand tu en as besoin, point barre. Chaque langage fait son choix du traitement des valeurs et des références, rien de nouveau sous le soleil.

Autre exemple ??

Relis l'exemple: maFonction est simplement un exemple d'un objet global auquel j'accède dans ma fonction anonyme.

Tout ça pour répondre au besoin que tu exprimais (pour ne plus te froisser, parce que ça ressemblait plutôt à une affirmation fausse):

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é

Tu vois bien que maFonction qui est globale, est accédée sans faire appel à global(). Et la fonction anonyme n'est pas nommée. Je recommence:

map(lambda fonctionAnonyme:x,g=objetGlobalQuelconque : <corps de la fonction anonyme>, liste)


Et encore une fois, si tu penses qu'on ne se comprend pas, prends un exemple concret en perl, que je te le transcrive en python.

Si, si, les fermetures sont bien sûr possibles en Python:

def maFonction(arg):
    pass

# On applique maFonction à dous les élément de la liste
map(lambda x,f=maFonction:f(x), liste)

Évidemment sans ça tu devais être emmerdé. Mais vas-y, exprime tes besoins en perl, et je te les transcris en python !

fonctions anonymes castrées

;-)
les pauvres !

Je vais pas avoir le temps de répondre à tout aujourd'hui...
allons-y toujours bien pour les formes fonctionnelles : je ne discuterai pas de leur intérêt, tu prêches un convaincu.

Mais justement, tu as dû passer à côté en python, parce que tout ce que tu peux
faire en perl, tu peux le faire en python !

L'équivalent de:

@nouvelle_liste = map { $somme += $_; 2*$_ } @liste;

en python est:

nouvelle_liste = map(lambda x:2*x,liste)
somme = sum(nouvelle_liste)

Ca pourra te paraître imbitable si tu ne connais pas le Perl et sa variable implicite $_

ben justement, j'étais fervent partisan de perl... avant de me convertir à python (ce qui n'a pas été immédiat).

Donc, concernant les lambda-forms, propose-moi une forme en perl, et je te donne l'équivalent en python.

Mais jusqu'à preuve du contraire, ça te fait un argument de moins.

*Sincèrement* désolé pour l'agressivité.

Je suis entouré de gens qui proposent comme solutions du code illisible, torché en 2 minutes, et dont je sais pertinemment qu'ils poseront plus de problème qu'ils n'en résoudront sur le long terme.

Dans le même temps, je suis horrifié par le code des outils de la Mandrake, *objectivement* très peu documenté et lisible. Ça me fait sincèrement chier de voir l'effort nécessaire pour les maintenir, à côté des outils de la Fedora, certes pas aussi avancés mais limpides à parcourir, et en plein boom.

Et sur ce je vois ton journal, dont le ton est, sinon agressif, très provocateur : une merveille d'un côté, quelque chose de forcément bien plus long et plus chiant en Python de l'autre... avoue que tu y es pas allé de main morte !!

Alors j'ai répondu à ta provocation, d'autant plus que je suis absolument persuadé que ce que tu prônes, c'est pour moi un exemple à ne pas suivre. Quelle que soit la finalité du code, d'ailleurs, ça ne rentre pas en ligne du compte dès l'instant où ça s'intègre au sein d'un travail d'équipe.

Donc enterrons provocation et agressivité... et dis-moi ce que tu penses de l'équivalent en python... tu n'es pas tenté ?