GaMa a écrit 447 commentaires

Et j'ai pas demander de faire une boucle sur un iterable, juste de tester si ça l'est (principe du duck-typing)

Je te cite, tu veux savoir si c'est iterable avant de le faire.
Et je me répète, la syntaxe "(x for x in iterable)" ne parcourt pas iterable. Ça crée un générateur qui parcourra iterable quand on itèrera le générateur.

Raté, c'est pas mon code, mais le code d'exemple que j'ai donné est issu de très grosses librairies python mondialement utilisées. Rhodecode, DJango, Pylon, et même la lib standard Python si mes souvenirs sont exacts !!!…

Si des softs sont mal codé, c'est la faute au dev, pas du langage et son de typage dynamique.

Matthieu Gautier|irc:starmad

À 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

Je m'y attendais à celle-là =)

l = [x for x in foo()]
# est equivalent a
def bar(iterable):
   ret = []
   for i in iterable:
       ret.append(i)
   return ret
l = bar(foo())
type(l) # <type 'list'>

l = (x for x in foo())
# est equivalent a
def bar(iterable):
   for i in iterable:
       yield i
l = 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.

Matthieu Gautier|irc:starmad

Ben c'est pas le même problème aussi.

def function(input):
    """
    Take an input that may be a iterable or not.
    """

    iterable = None
    if isinstance(input, basestring):
        """ basestring is the only particular case as it is also an iterable"""
        iterable = (input, )
    else:
        try:
            iterable = (x for x in input)
        except TypeError:
            iterable = (input, )
    if iterable is not None:
        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)

Matthieu Gautier|irc:starmad

Et ?

foo() retourne un générateur qui est un iterable. Il est où le problème ?

Matthieu Gautier|irc:starmad

def function(input):
    """
    Take an input that may be a iterable or not.
    """

    if isinstance(input, basetring):
        """ basetring is the only particular case as it is also an iterable"""
        do_the_stuff(input)
    else:
        try:
            iterable = (x for x in input)
        except TypeError:
            iterable = (input, )
        for i in iterable:
            do_the_stuff(i)

Matthieu Gautier|irc:starmad

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(String name)

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

Matthieu Gautier|irc:starmad

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 en plus, trouve-moi un seul mec qui va m'écrire ce code python du 1er coup…

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

public ArrayList read () throws java.io.FileNotFoundException, java.io.IOException
{
    FileReader fr = new FileReader (this.getFileName());
    BufferedReader br = new BufferedReader (fr);
    ArrayList aList = new ArrayList (this.getBufferSize());

    String line = null;
    while (     (line = br.readLine()) != null)
    {
        aList.add(line);
    }

    br.close();
    fr.close();

    return aList;
}

Matthieu Gautier|irc:starmad

tu peux faire du day_t() avec une macro

#define day(x) (day_t<(x)>())

Matthieu Gautier|irc:starmad

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:

def removeFeathers(self, duck):
    try:
        self.feathers += duck.feathers
        duck.feathers = 0
        print "Feathers removed"
    except AttributeError:
        print "no feather"

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

pour trouver une marque on a tendance à taper "marque.com" ou "marque.fr" et généralement ça fonctionne.

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

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 ?

Matthieu Gautier|irc:starmad

C'est aussi ce que je proposerait.

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

Matthieu Gautier|irc:starmad

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.

Matthieu Gautier|irc:starmad

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

Matthieu Gautier|irc:starmad

Bon je revient à la charge avec une solution plus propre qui devrait plaire à pas mal de monde (enfin j'espère) :

wrapper.py:

class Wrapper(object):
    def __init__(self, **kwords):
        self.kwords = kwords
        self.functions = {}

    def add_function(self, function):
        self.functions[function.func_name] = function

    def __getattr__(self, functionName):
        try:
            func = self.functions[functionName]
        except KeyError:
            raise AttributeError

        def wrapFunction(*args, **kwords):
            argsNeeded = list(func.func_code.co_varnames)
            argsDict = {}
            for i, arg in enumerate(args):
                argsDict[argsNeeded[i]] = arg
            for key, val in kwords.items():
                if key in argsDict:
                    raise TypeError("%s() got multiple values for keyword argument '%s'"%(functionName, key))
                argsDict[key] = val
            for key,val in self.kwords.items():
                if key not in argsDict and key in argsNeeded:
                    argsDict[key] = val
            for arg in argsNeeded[:-len(func.func_defaults or [])]:
                if arg not in argsDict:
                    raise TypeError("%s() need argument '%s'"%(functionName,arg))
            return func(**argsDict)
        return wrapFunction

test.py:

#!/usr/bin/env python

from wrapper import Wrapper


def function1(arg1, arg2, recurrent_arg, default_arg="default"):
        print arg1, arg2, recurrent_arg, default_arg

def function2(recurrent_arg, another_recurrent_arg):
        print recurrent_arg, another_recurrent_arg


def function3(arg1, arg2, recurrent_arg):
        wrapper = Wrapper(recurrent_arg=recurrent_arg)
        wrapper.add_function(function1)
        wrapper.add_function(function2)

        print "1 =>",
        function1(arg1,arg2,recurrent_arg)

        print "2 =>",
        wrapper.function1(arg1,arg2,recurrent_arg)

        print "3 =>",
        wrapper.function1(arg1,arg2)

        print "4 =>",
        wrapper.kwords["recurrent_arg"] = 42
        wrapper.function1(arg1,arg2)

        print "5 =>",
        wrapper.kwords["default_arg"] = 3.14
        wrapper.function1(arg1,arg2)

        print "6 =>",
        wrapper.function1(arg1,arg2,3)

        print "7 =>",
        wrapper.function1(arg1, default_arg="cool", arg2=42)

        print "8 =>",
        wrapper.kwords["arg1"]=100
        wrapper.function1(default_arg="cool", arg2=42)

        print "9 =>",
        wrapper.function2(another_recurrent_arg="another")

        print "10 =>",
        wrapper.kwords["another_recurrent_arg"] = "again"
        wrapper.function2()


function3(1, 2, 3)

Ça donne :

1 => 1 2 3 default
2 => 1 2 3 default
3 => 1 2 3 default
4 => 1 2 42 default
5 => 1 2 42 3.14
6 => 1 2 3 3.14
7 => 1 42 42 cool
8 => 100 42 42 cool
9 => 42 another
10 => 42 again

Matthieu Gautier|irc:starmad

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.

Matthieu Gautier|irc:starmad

def function1(arg1, arg2):

devient

def function1(self, arg1, arg2):

pareil pour fonction2

Matthieu Gautier|irc:starmad

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

Faut probablement l'améliorer et l'adapter à tes besoins mais ça marche.

Le code devrait parler de lui même:

#!/usr/bin/env python

def _function1(name, arg_recurrent):
        """ this function just print there args.
        We want to make it callable with only one arg"""
        print name, arg_recurrent


def defaultArg(function, **defaultArgs):
        """ wrap a function to automatically add defaultArgs to the call"""
        def newFunction(*args, **kwords):
                for k, item in defaultArgs.items():
                        kwords.setdefault(k, item)
                return function(*args, **kwords)
        return newFunction

def canCall(functionToWrap):
        """ Automatically replace functionToWrap by wrap of functionToWrap when calling the function"""
        def decorator(function):
                def newFunction(*args, **kwords):
                        newfunctionToWrap = defaultArg(functionToWrap, arg_recurrent=kwords.get("arg_recurrent",args[-1]))
                        function.func_globals[functionToWrap.func_name] = newfunctionToWrap
                        function(*args, **kwords)
                        function.func_globals[functionToWrap.func_name] = functionToWrap
                return newFunction
        return decorator

# create a new function
function1 = defaultArg(_function1, arg_recurrent=3.14)

def function2(arg_recurrent):
        """ create the fonction in the local namespace"""
        function1 = defaultArg(_function1, arg_recurrent=arg_recurrent)
        function1("function2")

def function3():
        """ use the global function"""
        function1("function3")

@canCall(_function1)
def function4(arg_recurrent):
        # here we call the wrapped version of _function1
        _function1("function4")


@canCall(_function1)
def function5(arg_recurrent):
        print arg_recurrent,
        arg_recurrent += 10
        print arg_recurrent,
        _function1("function5")

arg_r = 42
function2(arg_r)
function3()
function4(arg_r+1)
function4(arg_r-1)
function1("main")
_function1("_function1", 52)
function5(arg_r)

class Int:
        def __init__(self, value):
                self.value = value

        def __iadd__(self, value):
                self.value += value

        def __str__(self):
                return str(self.value)

function5(Int(arg_r))

Matthieu Gautier|irc:starmad

Et chez Fedora ils travaillent pour RH, c'est ça ?

Bah vu qu'une bonne partie ont des adresses email en @redhat.com, il y a des chances.

Au hasard, tu prends le comité technique de Fedora, tu as six membres sur neuf qui bossent chez RH.

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

Il apparaît en fait que les devs d'udev sont les même que que ceux qui ont poussé Fedora sur cette voie, de façon plus ou moins unilatérale.

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

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

Je suis sous FF12

• google.fr configurer pour faire des recherche en anglais => ça marche, pas de message
• google.com => ça marche, message
• google.fr après avoir cliqué sur le lien «Google.fr offered in: français» (donc recherche en français) => ça marche, message

Matthieu Gautier|irc:starmad

it accepts responsibility for:

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