Discussion :

[rosty38]

merci a vous , wiztricks et eyquem, grâce a vos proposition j'ai pu avancer, j'ai transformé un code de 900 ligne a un code de 80 ligne et ca marche , en utilisant la méthode proposé par wiztricks c.a.d celle qui utilise 'PARTIAL' .
après je pense que tout seul je n'aurai pas trouvé car il faut connaitre le module functools
en espérant que sa va servir a d'autre
encore merci

[wiztricks]

Salut,

après je pense que tout seul je n'aurai pas trouvé car il faut connaitre le module functools en espérant que sa va servir a d'autre
encore merci

Partial est une solution pour créer un callable avec à priori une liste partielle d'arguments. Ici, la liste est "complète", on pourrait s'en passer:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
if __name__ == '__main__':
     for v in list_tests.itervalues():
        for item in v:
            f =  item[0]
            args = item[1:]
            f(*args)

Mais je trouve plus "simple" d'avoir une liste de callables. Ca permet de ne pas avoir à dépendre de la représentation i.e. savoir que c'est un tuple dans lequel...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if __name__ == '__main__':
     for v in list_tests.itervalues():
        for f in v:
            f()

- W

[eyquem]

@ rosty38,
Si ça ne te gène pas, donne ton code, stp.
Je parie qu’on va trouver de quoi réduire le nombre de lignes à 24.

[dividee]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
if __name__ == '__main__':
    import sys
    module = sys.modules[globals()['__name__']]
    for v in list_tests.itervalues():
        for item in v:
            f = getattr(module, item[0])
            args = item[1:]
            f(*args)

Cela me semble plus compliqué que nécessaire...
Déjà, pourquoi écrire globals()['__name__'] quand __name__ aurait suffit ?
Mais surtout je vois pas trop pourquoi récupérer le module courant, alors qu'on peut accéder à son __dict__ directement avec globals:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
if __name__ == '__main__':
    for v in list_tests.itervalues():
        for item in v:
            f = globals()[item[0]]
            args = item[1:]
            f(*args)

Ca fait la même chose, non ?

[wiztricks]

Ah tiens salut dividee,

Cela me semble plus compliqué que nécessaire...
Déjà, pourquoi écrire globals()['__name__'] quand __name__ aurait suffit ?
Mais surtout je vois pas trop pourquoi récupérer le module courant, alors qu'on peut accéder à son __dict__ directement avec globals:

Ca fait la même chose, non ?

Ca fait la même chose et ce n'est pas la même chose. Strange non?

Crois-tu que les fonctions à tester seront dans le même module que celui ou sont déclarés et lancés les tests - le module courant - ?
J'espère que non.

J'ai donc anticipé la réponse à une question à venir: "comment récupérer une variable dans le globals d'un autre module?" en suggérant les éléments qui permettent d'y arriver...

Bien sûr, en se contentant de lire le code sans prendre le temps de comprendre le contexte, cela est "plus compliqué que nécessaire". Mais le code n'est qu'une illustration et non le contenu de cette discussion.

Enfin, tu auras pu lire que cette solution n'a, à priori, pas été retenue.

- W

[dividee]

Salut wiztricks,

Crois-tu que les fonctions à tester seront dans le même module que celui ou sont déclarés et lancés les tests - le module courant - ?
J'espère que non.

J'ai donc anticipé la réponse à une question à venir: "comment récupérer une variable dans le globals d'un autre module?" en suggérant les éléments qui permettent d'y arriver...

OK, mais ça va quand-même mieux en le disant. Sinon on se prend une remarque d'une andouille qui ont pas compris l'objectif

Enfin, tu auras pu lire que cette solution n'a, à priori, pas été retenue.

Utilisation intéressante de partial. Dans ce cas-ci, partial(f1,1) est équivalent à lambda: f1(1) vu que tous les arguments sont donnés. J'aurais plutôt utilisé lambda, car cela donnera une erreur si on oublie des arguments; avec partial on risque de ne pas s'en apercevoir tout de suite.
A moins que là aussi c'est pour anticiper... Non, je crois pas

[wiztricks]

Hello Dividee

OK, mais ça va quand-même mieux en le disant. Sinon on se prend une remarque d'une andouille qui ont pas compris l'objectif

La difficulté ici est que le code ne fait qu'illustrer des idées, montrer ce qu'on peut utiliser pour... Comme c'est "pas fini" et "hors contexte" on ne peut pas le lire, l'auditer de la même façon.

Utilisation intéressante de partial. Dans ce cas-ci, partial(f1,1) est équivalent à lambda: f1(1) vu que tous les arguments sont donnés. J'aurais plutôt utilisé lambda, car cela donnera une erreur si on oublie des arguments; avec partial on risque de ne pas s'en apercevoir tout de suite.

Bonne remarque, car l'idée étant de tester la 'validité' dans la construction de la liste de tests, çà va dans le bon sens.
Mais je n'arrive pas à le faire marcher

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
def foo(a, b): print a+b
x = lambda: foo(1)
# ne retourne une erreur que lorsqu'on invoke x

Ce qui ne me semble pas anormal... mais pour le coup, je n'ai peut être pas compris ta remarque.

A moins que là aussi c'est pour anticiper... Non, je crois pas

Dans l'exemple, la construction de la liste est "statique". Mais on pourrait imaginer qu'elle soit construite par des fonctions qui la construise à partir d'un fichier.

Soucis: est-ce qu'on "variabilise" le paquets de strings lors de sa construction ou lors de son parcours pour exécuter les tests?

La mouture "partial" variabilise "à la construction" et on en profite pour transformer (f, a, b,... ) en callable et séparer les erreurs de construction des erreurs d'exécution.

Cette séparation aurait sans doute été plus lisible en définissant une fonction, style:
>>> def make_callable(f, *args, **kwds):
... return lambda: f(*args, **kwds)
habillable ensuite avec des inspect.machin pour fiabiliser les tests.
J'ai peut être manqué d'inspiration sur ce coup là, j'en conviens.
- W

[dividee]

Mais je n'arrive pas à le faire marcher

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
def foo(a, b): print a+b
x = lambda: foo(1)
# ne retourne une erreur que lorsqu'on invoke x

Ce qui ne me semble pas anormal... mais pour le coup, je n'ai peut être pas compris ta remarque.

C'est moi qui me suis mélangé les pinceaux, désolé. J'aime beaucoup la curryfication automatique qu'il y a en ML ou en haskell; du coup j'ai bêtement cru que partial retournait une version curryfiée de la fonction, et que donc x() (où x est le résultat d'un appel à partial) ne causerait pas une erreur mais renverrait la fonction x elle-même. C'est bien sûr totalement faux.

Dans l'exemple, la construction de la liste est "statique". Mais on pourrait imaginer qu'elle soit construite par des fonctions qui la construise à partir d'un fichier.

Soucis: est-ce qu'on "variabilise" le paquets de strings lors de sa construction ou lors de son parcours pour exécuter les tests?

La mouture "partial" variabilise "à la construction" et on en profite pour transformer (f, a, b,... ) en callable et séparer les erreurs de construction des erreurs d'exécution.

S'il manque un argument, est-ce une erreur dans la construction des tests ou dans le code qui est testé, qui déclare un paramètre de trop ? Dans le premier cas, on peut souhaiter séparer les deux (càd faire échouer l'exécution du test), dans le second, on préférerait sans doute que le test s'exécute mais renvoie une erreur...

Cette séparation aurait sans doute été plus lisible en définissant une fonction, style:
>>> def make_callable(f, *args, **kwds):
... return lambda: f(*args, **kwds)
habillable ensuite avec des inspect.machin pour fiabiliser les tests.
J'ai peut être manqué d'inspiration sur ce coup là, j'en conviens.
- W

inspect.machin ? Moi à ce moment je commencerais à chercher un framework de test existant, histoire de voir si quelqu'un aurait pas déjà fait le boulot à ma place