À oui ? Parce qu'il y a un générateur au milieu ? On fait du python je te rappelle, c'est pas les appels de fonction qui coute le plus cher. (surtout que c'est un générateur "builtin", donc optimisé)
l=[xforxinfoo()]# est equivalent adefbar(iterable):ret=[]foriiniterable:ret.append(i)returnretl=bar(foo())type(l)# <type 'list'>
l=(xforxinfoo())# est equivalent adefbar(iterable):foriiniterable:yieldil=bar(foo())type(l)# <type 'generator'>
Same player shoot again ?
On revient à ce que je disais, tu codes en python comme tu codes en java: Tu veux savoir si c'est du type iterable avant de travailler dessus.
En python on s'en fout : on essaye et si ça passe pas c'est que c'est pas un iterable.
deffunction(input):""" Take an input that may be a iterable or not. """iterable=Noneifisinstance(input,basestring):""" basestring is the only particular case as it is also an iterable"""iterable=(input,)else:try:iterable=(xforxininput)exceptTypeError:iterable=(input,)ifiterableisnotNone:do_the_stuff(iterable)
C'est mieux comme ça ?
(En même temps, tu me donnes un itérable infini et tu me demandes de boucler dessus, je m’arrête jamais moi. Quel que soit le langage ou le typage)
deffunction(input):""" Take an input that may be a iterable or not. """ifisinstance(input,basetring):""" basetring is the only particular case as it is also an iterable"""do_the_stuff(input)else:try:iterable=(xforxininput)exceptTypeError:iterable=(input,)foriiniterable:do_the_stuff(i)
Et en quoi "@return lignes du fichier" m'indique le type retourné ? String, liste de string ? tuple de string ? générateur de string ? (ESOF des trois derniers tant que c'est un iterable de string ?)
List<String>read(Stringname)
Et en quoi, quand je lit juste la signature de la fonction, je sais que "name" doit être le chemin (absolu?) d'un fichier ? Et que ça retourne le contenu du fichier ?
Non c'est plutôt cohérent avec ce qui avait était dis au dessus comme quoi le typage statique est remplacé par de la doc.
Pour moi c'est un bien pour un mal. Tu gagnes en flexibilité mais faut être un peu plus carré sur ce que tu fais (ce que tous le monde ne fait pas, moi le premier).
Après je vous l'accorde, il manque peut être à python un truc permettant de définir l'interface attendu des arguments (mais je suis pas totalement sûr, un canard peut avoir des plumes après être entré dans la ferme).
Si tu prends le add(duck) précédent, soit tu le documentes avec un simple duck : canard à ajouter, doit être de type Duck ou dérivé et autant avoir un joli compilateur pour faire ce travail de vérif en plus de perdre tout intérêt au duck-typing, soit tu le documentes avec un gros duck : canard à ajouter, doit répondre à la méthode fly, quack, swim et posséder les attributs feathers, qui, en plus de ne sûrement pas être exaustif, sera une simple plaie ambulante à maintenir…
Oui, mais pour moi le principal problème vient du fait que tu veux les avantages du typage statique avec un langage à typage dynamique, ça peut tous simplement pas marcher (tout seul).
Ta fonction addDuck, elle ne prend pas un duck comme argument mais un truc qui à les méthode fly, quack et swim (point). Elle devrait d’ailleurs s’appeler add (pas de raison qu'une ferme accepte que des canards)
Si tu veux un duck faut faire du isinstance. (Et la tu perds l'avantage du python)
De la même façon, removeFeathers prend un truc à plume, pas un canard.
Un canard sans plume c'est peu être un canard mais c'est pas un truc à plume. Faut pas chercher plus loin.
Si tu veux une fonction qui prend un truc qui peut avoir des plumes, c'est ça:
Dans tous les cas, tu ne peux pas faire du python comme tu ferais du c++. C'est pas la faute du python ou du typage dynamique, c'est la faute au dev qui veut du typage statique dans python. Les paradigmes sont différents, faut coder différemment.
J'ai un pool de jours par an à ma disposition (~0,5 jours par semaine). Et j'ai la maîtrise technique du projet (dans les limites que m'imposeront pe ou pe pas mes chefs au fur et à mesure du temps).
Le temps de dev pour répondre à la demande du client serait en plus des 0.5 jours ou te devra le faire pendant cette demi-journée ?
J'ai bossé une boite qui fait de l'open source. Ils ont deux sites:
Un en .org qui est le site du projet (doc, forum, …)
Un autre en .com qui est la version pro (service de dev, formation, …)
Le soft est pas mal géré par la boite elle même (licence "perso") mais il y a quand même quelques patch d'autre entreprise (partenaires). Elle vend même une version propriétaire à des clients avec des fonctionnalités particulières.
Tu pourrais proposer une double version (avec deux sites). Si tu propose de ne pas faire de dev payant et de diriger toutes les opportunités commerciales vers ta boite (dans la limite des clauses de loyauté et non concurrence), ton patron pourrait accepter.
Je suis globalement d'accord avec les commentaires précédents sur le fait que le code ne t'appartient pas. Par contre pour le site web je suis moins sur. Ce n'est probablement pas ton corps de métier, ça peut donc s'apparenter à du code perso. Si c'est le cas (à voir avec un juriste) tu peux tous simplement refuser de le donner à ta boite. C'est un point en plus de ton coté pour la négo.
De plus, même si tu ne l'a pas fait dans ce sens, tu as associé ton nom au projet. Tu as donc une certaine renommé. Si tu fork il faut se poser la question de "qui sera suivi par la communauté ? toi ou ta boite ?"
(Il te faudra peut être négocier un peu moins brutalement que j'en parle ;-)
Ouai… en même temps t'as tendance à t'enflammer rapidement.
un parti qui milite pour une société entièrement libre et débarrassée de tous les intérêts industriels et financiers
Moi je lit : "une société libre (et débarrassée) de tous les intérêts industriels et financiers". C'est différent de "une société libre […]"
Certes la phrase est ambigüe et ton interprétation n'est pas obligatoirement mauvaise, mais tu pourrais laisser le bénéfice du doute avant d'être méprisant.
J'espère que tu ne le prends pas mal (j'ai vaguement eu cette impression dans tes commentaires précédents)
Un peu, mais ça va, je vais mieux maintenant :-)
Je suis globalement d'accord avec toi : Il ne faut pas faire des trucs compliqués juste pour l'envie/parce qu'on sait le faire.
Il n'empêche que si la POO répond à beaucoup de problématiques, ce n'est pas la solution à tous les problèmes.
Ce n'est pas parce que des fonctions utilisent un ensemble communs de paramètres qu'il faut obligatoirement les regrouper dans une même classe.
L'exemple bidon que je vois rapidement c'est un système de véhicules (avec les héritages voiture, camion, …) qui se déplace sur plusieurs terrains.
Ce n'est pas parce que la majorité des méthodes de Vehicule utilise les mêmes paramètres (relatifs à l'environnement) qu'ils doivent être mis dans la classe Vehicule. (Tu me diras que ça doit être mis dans la classe Terrain et qu'il faut passer un objet Terrain aux méthodes alors je te répondrais que je suis d'accord mais que ce n'est pas dans la classe Vehicule)
Ça s'apparente plus ici à une programmation par contexte. C'est pas de la POO (bien que ça l'utilise en interne) c'est autre chose. On pourrait avoir un code de ce genre:
context1=Context(vehicule1,terrain1)context2=Context(vehicule2,terrain)compare_context(context1,context2)context1.fonction_de_vehicule()# dans le context1context1.fonction_de_vehicule(vitesse_vent=5)# dans le context1 mais avec un vent de 5m/s
Python fournit beaucoup de fonctionnalités qui sortent de la POO classique (duck typing, metaclass, decorator, introspection du code, … ). Ce ne sont pas des trucs alambiqués qui dénaturent python. C'est juste que python n'est pas C++ ou java.
Ne pas utiliser ces fonctionnalités (cette puissance) juste parce que c'est pas de la POO est stupide (l'utiliser juste parce que c'est disponible est aussi stupide). Il faut voir en fonction du besoin, que je ne connait pas (comme toi).
Après je suis désolé, ma classe Wrapper (qui devrait s'appeler Context) n'est pas compliqué. Elle mérite peut être quelques commentaires et fonctions intermédiaires mais la base de l'algo est extrêmement simple : utiliser un dictionnaire de valeur pour remplir les "trous" dans les arguments lors d'un appel de fonction. Ça se résume en 20/30 lignes et c'est générique.
Certes ça demande de comprendre ce qu'il se passe et ça change par rapport à la POO. Mais la POO a apporté les mêmes changements par rapport à la programmation procédural. Ce n'était pas une mauvaise chose et ça ne l'a pas remplacé. (je n'ai toutefois pas la prétention d'inventer un nouveau paradigme de programmation)
Moi, je répond juste à la question. Je dit pas que c'est ce qu'il faut faire (vous le faites suffisamment bien, pas besoin que j'en rajoute une couche).
Par contre, j'ai trouvé que c'était un bon exercice, j'y ai réfléchi et j'ai trouvé une solution, je la partage.
Niveau complexité, certes c'est plus compliqué qu'une variable globale ou une classe, mais le code important se résume à une dizaine de lignes, c'est pas ce qui est du plus compliqué.
Après je te rassure (si jamais tu pouvais potentiellement t'inquiéter de ce que je puisse faire) l'idée ne me serais même pas venu à l'esprit. Je préfèrerait encore me taper le copier-coller des arguments.
De plus je ne connais pas le problème réel de Jiehong.
La fonction à appeler peut être une fonction d'un module extérieur (donc impossibilité de la modifier)
Il y a peut être une dizaine d'arguments identiques, ce qui expliquerait qu'il n'est pas envie de les répéter 36 fois (même si ça peut se simplifier à coup de [] ou *{})
À ce moment, que tu utilises des classe et des globales, tu te retrouves quand même à faire des wrappers(/lambdas/méthodes).
Et si tu as 10 fonctions à wrappers que tu utilises dans une 10aine de tes fonctions tu te retrouves à faire des wrappers à tous va (éventuellement un peu partout dans ton code). À ce moment le code est plus simple mais à maintenir c'est le bordel.
Je répond juste à sa question. C'est lui le dev de son projet, à lui de savoir ce qu'il doit utiliser.
Ha ben quand on veut pas faire des trucs standards faut pas s'étonner que la solution soit pas super propre. Et puis il y a seulement deux fonctions utiles dans mon code, le reste c'est des exemples.
Après, pour avoir une variable commune à plusieurs fonctions mais pas à toutes, LA solution python (et pas que) c'est l'objet.
Mais c'est pas vraiment ce qui est demandé. Ce que veut Jiehong c'est rajouter des closures à des fonctions. Ça doit être possible mais ça demande de descendre très bas au niveau des objets python, accéder au code des fonctions en dynamique et recréer un objet code en y rajoutant les closures. Mais ça ne se fait pas en deux heures.
Le fait d'utiliser des objets oblige à mettre du self partout. Ça répond pas au problème qui est d'éviter de passer un argument à une fonction.
Faut probablement l'améliorer et l'adapter à tes besoins mais ça marche.
Le code devrait parler de lui même:
#!/usr/bin/env pythondef_function1(name,arg_recurrent):""" this function just print there args. We want to make it callable with only one arg"""printname,arg_recurrentdefdefaultArg(function,**defaultArgs):""" wrap a function to automatically add defaultArgs to the call"""defnewFunction(*args,**kwords):fork,itemindefaultArgs.items():kwords.setdefault(k,item)returnfunction(*args,**kwords)returnnewFunctiondefcanCall(functionToWrap):""" Automatically replace functionToWrap by wrap of functionToWrap when calling the function"""defdecorator(function):defnewFunction(*args,**kwords):newfunctionToWrap=defaultArg(functionToWrap,arg_recurrent=kwords.get("arg_recurrent",args[-1]))function.func_globals[functionToWrap.func_name]=newfunctionToWrapfunction(*args,**kwords)function.func_globals[functionToWrap.func_name]=functionToWrapreturnnewFunctionreturndecorator# create a new functionfunction1=defaultArg(_function1,arg_recurrent=3.14)deffunction2(arg_recurrent):""" create the fonction in the local namespace"""function1=defaultArg(_function1,arg_recurrent=arg_recurrent)function1("function2")deffunction3():""" use the global function"""function1("function3")@canCall(_function1)deffunction4(arg_recurrent):# here we call the wrapped version of _function1_function1("function4")@canCall(_function1)deffunction5(arg_recurrent):printarg_recurrent,arg_recurrent+=10printarg_recurrent,_function1("function5")arg_r=42function2(arg_r)function3()function4(arg_r+1)function4(arg_r-1)function1("main")_function1("_function1",52)function5(arg_r)classInt:def__init__(self,value):self.value=valuedef__iadd__(self,value):self.value+=valuedef__str__(self):returnstr(self.value)function5(Int(arg_r))
Pour moi, ça veut dire "t’inquiète je gère. T'as fait le boulot comme il faut"
"it accepts responsibility for" != "it WILL do one of :"
Après je suis d'accord avec toi, c'est un peu osé de virer des messages directement sans avertissement (même si je comprend les raisons techniques). C'est au client du serveur de pousser une gueulante, mais smtp est respecté.
Le postier n'est pas concerné par le fait que ta boite aux lettres soit en fait une poubelle. Il a mit la lettre dans la boite aux lettres qui va bien, terminé!
De la même façon, si tu pars en vacance et que ta boite se remplie, le postier peut plus mettre la lettre dans la boite => message d'erreur. (et que ce soit du courrier légitime ou du spam, rien a f***)
Manquerai plus que lorsque j'aille a une poste pour envoyer un colis, l'hôtesse de caisse me dit oui pas de problème, prenne mon colis pour le benner dès que j'ai le dos tourné.
En même temps l’hôtesse c'est TON serveur smtp. Encore heureux qu'il te dise oui et qu'il l'envoie.
Le serveur smtp du destinataire, c'est sa concierge. Si le mec demande à sa concierge de jeter les prospectus publicitaire et qu'elle se plante et jette tes colis, c'est leur problème pas le tien.
[^] # Re: Le titre est trop long
Posté par GaMa (site web personnel) . En réponse au journal Typage statique versus typage dynamique. Évalué à 0.
À oui ? Parce qu'il y a un générateur au milieu ? On fait du python je te rappelle, c'est pas les appels de fonction qui coute le plus cher. (surtout que c'est un générateur "builtin", donc optimisé)
Matthieu Gautier|irc:starmad
[^] # Re: Le titre est trop long
Posté par GaMa (site web personnel) . En réponse au journal Typage statique versus typage dynamique. Évalué à 1.
Je m'y attendais à celle-là =)
Same player shoot again ?
On revient à ce que je disais, tu codes en python comme tu codes en java: Tu veux savoir si c'est du type iterable avant de travailler dessus.
En python on s'en fout : on essaye et si ça passe pas c'est que c'est pas un iterable.
Matthieu Gautier|irc:starmad
[^] # Re: Le titre est trop long
Posté par GaMa (site web personnel) . En réponse au journal Typage statique versus typage dynamique. Évalué à 2.
Ben c'est pas le même problème aussi.
C'est mieux comme ça ?
(En même temps, tu me donnes un itérable infini et tu me demandes de boucler dessus, je m’arrête jamais moi. Quel que soit le langage ou le typage)
Matthieu Gautier|irc:starmad
[^] # Re: Le titre est trop long
Posté par GaMa (site web personnel) . En réponse au journal Typage statique versus typage dynamique. Évalué à 2.
Et ?
foo() retourne un générateur qui est un iterable. Il est où le problème ?
Matthieu Gautier|irc:starmad
[^] # Re: Le titre est trop long
Posté par GaMa (site web personnel) . En réponse au journal Typage statique versus typage dynamique. Évalué à 0. Dernière modification le 10 juillet 2012 à 13:58.
Matthieu Gautier|irc:starmad
[^] # Re: Le titre est trop long
Posté par GaMa (site web personnel) . En réponse au journal Typage statique versus typage dynamique. Évalué à 3.
Et en quoi "@return lignes du fichier" m'indique le type retourné ? String, liste de string ? tuple de string ? générateur de string ? (ESOF des trois derniers tant que c'est un iterable de string ?)
Et en quoi, quand je lit juste la signature de la fonction, je sais que "name" doit être le chemin (absolu?) d'un fichier ? Et que ça retourne le contenu du fichier ?
Pour moi c'est un bien pour un mal. Tu gagnes en flexibilité mais faut être un peu plus carré sur ce que tu fais (ce que tous le monde ne fait pas, moi le premier).
Après je vous l'accorde, il manque peut être à python un truc permettant de définir l'interface attendu des arguments (mais je suis pas totalement sûr, un canard peut avoir des plumes après être entré dans la ferme).
Matthieu Gautier|irc:starmad
[^] # Re: Le titre est trop long
Posté par GaMa (site web personnel) . En réponse au journal Typage statique versus typage dynamique. Évalué à 2.
Ah non, moi je lit 3 lignes de python, pas 8. Si tu comptes la docstring python faut que tu comptes aussi la javadoc pour être cohérent.
5 lignes en Java, 3 en Python, au coût de la ligne, je prend Python !!!
Et trouve moi un seul mec qui va m'écrire ce code java du 1er coup…
Généralement, c'est plutôt (exemple pris d'ici (4em résultat de la recherche google "java readfile"):
Matthieu Gautier|irc:starmad
[^] # Re: Le titre est trop long
Posté par GaMa (site web personnel) . En réponse au journal Typage statique versus typage dynamique. Évalué à 3.
tu peux faire du day_t() avec une macro
Matthieu Gautier|irc:starmad
[^] # Re: Le titre est trop long
Posté par GaMa (site web personnel) . En réponse au journal Typage statique versus typage dynamique. Évalué à 6.
Oui, mais pour moi le principal problème vient du fait que tu veux les avantages du typage statique avec un langage à typage dynamique, ça peut tous simplement pas marcher (tout seul).
Ta fonction addDuck, elle ne prend pas un duck comme argument mais un truc qui à les méthode fly, quack et swim (point). Elle devrait d’ailleurs s’appeler add (pas de raison qu'une ferme accepte que des canards)
Si tu veux un duck faut faire du isinstance. (Et la tu perds l'avantage du python)
De la même façon, removeFeathers prend un truc à plume, pas un canard.
Un canard sans plume c'est peu être un canard mais c'est pas un truc à plume. Faut pas chercher plus loin.
Si tu veux une fonction qui prend un truc qui peut avoir des plumes, c'est ça:
Dans tous les cas, tu ne peux pas faire du python comme tu ferais du c++. C'est pas la faute du python ou du typage dynamique, c'est la faute au dev qui veut du typage statique dans python. Les paradigmes sont différents, faut coder différemment.
Matthieu Gautier|irc:starmad
[^] # Re: Hein ?
Posté par GaMa (site web personnel) . En réponse au journal Et une kyrielle de domaines.... Évalué à 6.
pour trouver une marque on a tendance à taper "marque" et généralement google fonctionne.
La plupart des gens normaux n'ont aucune idée de si le site web de leur marque préférée est en com ou fr.
Matthieu Gautier|irc:starmad
[^] # Re: fork !
Posté par GaMa (site web personnel) . En réponse au journal Relations entre projet libre et entreprise. Évalué à 1.
Le temps de dev pour répondre à la demande du client serait en plus des 0.5 jours ou te devra le faire pendant cette demi-journée ?
Matthieu Gautier|irc:starmad
[^] # Re: Deux versions
Posté par GaMa (site web personnel) . En réponse au journal Relations entre projet libre et entreprise. Évalué à 3.
C'est aussi ce que je proposerait.
J'ai bossé une boite qui fait de l'open source. Ils ont deux sites:
Le soft est pas mal géré par la boite elle même (licence "perso") mais il y a quand même quelques patch d'autre entreprise (partenaires). Elle vend même une version propriétaire à des clients avec des fonctionnalités particulières.
Tu pourrais proposer une double version (avec deux sites). Si tu propose de ne pas faire de dev payant et de diriger toutes les opportunités commerciales vers ta boite (dans la limite des clauses de loyauté et non concurrence), ton patron pourrait accepter.
Je suis globalement d'accord avec les commentaires précédents sur le fait que le code ne t'appartient pas. Par contre pour le site web je suis moins sur. Ce n'est probablement pas ton corps de métier, ça peut donc s'apparenter à du code perso. Si c'est le cas (à voir avec un juriste) tu peux tous simplement refuser de le donner à ta boite. C'est un point en plus de ton coté pour la négo.
De plus, même si tu ne l'a pas fait dans ce sens, tu as associé ton nom au projet. Tu as donc une certaine renommé. Si tu fork il faut se poser la question de "qui sera suivi par la communauté ? toi ou ta boite ?"
(Il te faudra peut être négocier un peu moins brutalement que j'en parle ;-)
Matthieu Gautier|irc:starmad
[^] # Re: LO
Posté par GaMa (site web personnel) . En réponse au journal 0,76% de moyenne nationale pour le parti pirate, déception . Évalué à 5.
Ouai… en même temps t'as tendance à t'enflammer rapidement.
Moi je lit : "une société libre (et débarrassée) de tous les intérêts industriels et financiers". C'est différent de "une société libre […]"
Certes la phrase est ambigüe et ton interprétation n'est pas obligatoirement mauvaise, mais tu pourrais laisser le bénéfice du doute avant d'être méprisant.
Matthieu Gautier|irc:starmad
[^] # Re: wrapper et decorateur
Posté par GaMa (site web personnel) . En réponse au message Argument de fonction récurrent. Évalué à 2.
Un peu, mais ça va, je vais mieux maintenant :-)
Je suis globalement d'accord avec toi : Il ne faut pas faire des trucs compliqués juste pour l'envie/parce qu'on sait le faire.
Il n'empêche que si la POO répond à beaucoup de problématiques, ce n'est pas la solution à tous les problèmes.
Ce n'est pas parce que des fonctions utilisent un ensemble communs de paramètres qu'il faut obligatoirement les regrouper dans une même classe.
L'exemple bidon que je vois rapidement c'est un système de véhicules (avec les héritages voiture, camion, …) qui se déplace sur plusieurs terrains.
Ce n'est pas parce que la majorité des méthodes de Vehicule utilise les mêmes paramètres (relatifs à l'environnement) qu'ils doivent être mis dans la classe Vehicule. (Tu me diras que ça doit être mis dans la classe Terrain et qu'il faut passer un objet Terrain aux méthodes alors je te répondrais que je suis d'accord mais que ce n'est pas dans la classe Vehicule)
Ça s'apparente plus ici à une programmation par contexte. C'est pas de la POO (bien que ça l'utilise en interne) c'est autre chose. On pourrait avoir un code de ce genre:
Python fournit beaucoup de fonctionnalités qui sortent de la POO classique (duck typing, metaclass, decorator, introspection du code, … ). Ce ne sont pas des trucs alambiqués qui dénaturent python. C'est juste que python n'est pas C++ ou java.
Ne pas utiliser ces fonctionnalités (cette puissance) juste parce que c'est pas de la POO est stupide (l'utiliser juste parce que c'est disponible est aussi stupide). Il faut voir en fonction du besoin, que je ne connait pas (comme toi).
Après je suis désolé, ma classe Wrapper (qui devrait s'appeler Context) n'est pas compliqué. Elle mérite peut être quelques commentaires et fonctions intermédiaires mais la base de l'algo est extrêmement simple : utiliser un dictionnaire de valeur pour remplir les "trous" dans les arguments lors d'un appel de fonction. Ça se résume en 20/30 lignes et c'est générique.
Certes ça demande de comprendre ce qu'il se passe et ça change par rapport à la POO. Mais la POO a apporté les mêmes changements par rapport à la programmation procédural. Ce n'était pas une mauvaise chose et ça ne l'a pas remplacé. (je n'ai toutefois pas la prétention d'inventer un nouveau paradigme de programmation)
Matthieu Gautier|irc:starmad
[^] # Re: wrapper et decorateur
Posté par GaMa (site web personnel) . En réponse au message Argument de fonction récurrent. Évalué à 2.
Bon je revient à la charge avec une solution plus propre qui devrait plaire à pas mal de monde (enfin j'espère) :
wrapper.py:
test.py:
Ça donne :
Matthieu Gautier|irc:starmad
[^] # Re: wrapper et decorateur
Posté par GaMa (site web personnel) . En réponse au message Argument de fonction récurrent. Évalué à 2.
Moi, je répond juste à la question. Je dit pas que c'est ce qu'il faut faire (vous le faites suffisamment bien, pas besoin que j'en rajoute une couche).
Par contre, j'ai trouvé que c'était un bon exercice, j'y ai réfléchi et j'ai trouvé une solution, je la partage.
Niveau complexité, certes c'est plus compliqué qu'une variable globale ou une classe, mais le code important se résume à une dizaine de lignes, c'est pas ce qui est du plus compliqué.
Après je te rassure (si jamais tu pouvais potentiellement t'inquiéter de ce que je puisse faire) l'idée ne me serais même pas venu à l'esprit. Je préfèrerait encore me taper le copier-coller des arguments.
De plus je ne connais pas le problème réel de Jiehong.
À ce moment, que tu utilises des classe et des globales, tu te retrouves quand même à faire des wrappers(/lambdas/méthodes).
Et si tu as 10 fonctions à wrappers que tu utilises dans une 10aine de tes fonctions tu te retrouves à faire des wrappers à tous va (éventuellement un peu partout dans ton code). À ce moment le code est plus simple mais à maintenir c'est le bordel.
Je répond juste à sa question. C'est lui le dev de son projet, à lui de savoir ce qu'il doit utiliser.
Matthieu Gautier|irc:starmad
[^] # Re: Le global c'est bien pour du global
Posté par GaMa (site web personnel) . En réponse au message Argument de fonction récurrent. Évalué à 1.
devient
pareil pour fonction2
Matthieu Gautier|irc:starmad
[^] # Re: wrapper et decorateur
Posté par GaMa (site web personnel) . En réponse au message Argument de fonction récurrent. Évalué à 0.
Ha ben quand on veut pas faire des trucs standards faut pas s'étonner que la solution soit pas super propre. Et puis il y a seulement deux fonctions utiles dans mon code, le reste c'est des exemples.
Après, pour avoir une variable commune à plusieurs fonctions mais pas à toutes, LA solution python (et pas que) c'est l'objet.
Mais c'est pas vraiment ce qui est demandé. Ce que veut Jiehong c'est rajouter des closures à des fonctions. Ça doit être possible mais ça demande de descendre très bas au niveau des objets python, accéder au code des fonctions en dynamique et recréer un objet code en y rajoutant les closures. Mais ça ne se fait pas en deux heures.
Le fait d'utiliser des objets oblige à mettre du self partout. Ça répond pas au problème qui est d'éviter de passer un argument à une fonction.
Matthieu Gautier|irc:starmad
# wrapper et decorateur
Posté par GaMa (site web personnel) . En réponse au message Argument de fonction récurrent. Évalué à 1. Dernière modification le 01 juin 2012 à 14:44.
Faut probablement l'améliorer et l'adapter à tes besoins mais ça marche.
Le code devrait parler de lui même:
Matthieu Gautier|irc:starmad
[^] # Re: HFS
Posté par GaMa (site web personnel) . En réponse à la dépêche Sortie de Fedora 17 nommée Beefy Miracle. Évalué à 2.
En même temps le bureau est composé à la majorité de personnes issues de la communauté (et c'est un principe, pas seulement la situation actuelle)
Matthieu Gautier|irc:starmad
[^] # Re: HFS
Posté par GaMa (site web personnel) . En réponse à la dépêche Sortie de Fedora 17 nommée Beefy Miracle. Évalué à 1.
Donc c'est les dev d'udev qui veulent tout migrer vers /usr, pas vraiment Fedora ?
Dans ce cas les autres distrib sont obligées de suivre udev, pas Fedora. Fedora n'est que la première à le faire.
Matthieu Gautier|irc:starmad
[^] # Re: Un point de plus
Posté par GaMa (site web personnel) . En réponse au journal La seule et unique raison de refuse le vote par Internet. Évalué à 3.
Le problème reste le même : seul B peut déchiffrer chaque message, donc seul B décide des résultat du vote.
Matthieu Gautier|irc:starmad
[^] # Re: Chez moi ça marche
Posté par GaMa (site web personnel) . En réponse au journal Les gros sabots de Google. Évalué à 5.
Je suis sous FF12
Matthieu Gautier|irc:starmad
[^] # Re: C'est pas si simple l'email.
Posté par GaMa (site web personnel) . En réponse au journal Les emails par Neuf…. Évalué à 2.
Pour moi, ça veut dire "t’inquiète je gère. T'as fait le boulot comme il faut"
"it accepts responsibility for" != "it WILL do one of :"
Après je suis d'accord avec toi, c'est un peu osé de virer des messages directement sans avertissement (même si je comprend les raisons techniques). C'est au client du serveur de pousser une gueulante, mais smtp est respecté.
Le postier n'est pas concerné par le fait que ta boite aux lettres soit en fait une poubelle. Il a mit la lettre dans la boite aux lettres qui va bien, terminé!
De la même façon, si tu pars en vacance et que ta boite se remplie, le postier peut plus mettre la lettre dans la boite => message d'erreur. (et que ce soit du courrier légitime ou du spam, rien a f***)
Matthieu Gautier|irc:starmad
[^] # Re: C'est pas si simple l'email.
Posté par GaMa (site web personnel) . En réponse au journal Les emails par Neuf…. Évalué à 4.
En même temps l’hôtesse c'est TON serveur smtp. Encore heureux qu'il te dise oui et qu'il l'envoie.
Le serveur smtp du destinataire, c'est sa concierge. Si le mec demande à sa concierge de jeter les prospectus publicitaire et qu'elle se plante et jette tes colis, c'est leur problème pas le tien.
Matthieu Gautier|irc:starmad