Défi ? Assouplir l'appel d'une fonction

Version imprimable

Voir 40 message(s) de cette discussion en une page

23/06/2010, 14h34
rambc

Défi ? Assouplir l'appel d'une fonction
Bonjour,
j'ai le code suivant :
Code:

1 2 3 4 5 6 7 8 9 10 #! /usr/bin/env python #coding=utf-8 def rgb(r,g,b): print(r) print(g) print(b) print() rgb("r", "g", "b")
Je voudrais en fait avoir aussi la possibilité de faire un appel comme suit :
Code:

1 2 malist = ["r","g","b"] rgb(malist)
Est-ce possible ?

Je m'auto-réponds. Voici un principe, il reste à ajouter des procédures de vérification mais ce n'est pas mon propos ici :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 #! /usr/bin/env python #coding=utf-8 def rgb(*args): if len(args) == 1: args = args[0] for oneArg in args: print(oneArg) print() rgb("r","g","b") mylist = ["r","g","b"] rgb(mylist)

23/06/2010, 14h51
rambc

Merci c'est super. :ccool:

Voilà que je deviens schizophrène... :mouarf:
23/06/2010, 15h02
Zavonen
Félicitations !
Une fois de plus le vieil adage se vérifie: "L'enseignement n'est nécessaire que quand il est superflu!".
Tu as aussi cette possibilité, mais c'est moins bien que ce que tu proposes:
Code:

1 2 3 4 5 6 7 8 9 def rgb (L=[],r=0,g=0,b=0): if L!=[]: r=L[0] g=L[1] b=L[2] print r,g,b rgb(["r","g","b"]) rgb(r="rouge",g="vert",b="bleu")
23/06/2010, 15h03
Elenaher

Tu peux aussi passer par un dictionnaire si tu veux encore complexifier.

Je mets une référence ici si ca intéresse d'autres gens :

http://python.developpez.com/faq/?page=Fonction
23/06/2010, 15h42
rambc

Citation:

Envoyé par Zavonen

Une fois de plus le vieil adage se vérifie: "L'enseignement n'est nécessaire que quand il est superflu!".

Je suis févrieux :weird: donc il va falloir m'expliquer un peu cet adage... :cfou:

Citation:

Envoyé par Elenaher

Tu peux aussi passer par un dictionnaire si tu veux encore complexifier.

Je connaissais déjà mais à l'usage je n'en ai jamais eu vraiment besoin. De plus, mon problème est différent.
23/06/2010, 16h14
Zavonen

Citation:

Je suis févrieux donc il va falloir m'expliquer un peu cet adage...

C'est seulement en février qu'on est févrieux, en juin on peut être à la limite fiévreux.
Bon supposons que ce soit le cas, alors tu es tout excusé.
Un conseil, un tuyau, une aide, n'est utile pour un individu que dans la mesure où l'individu en question était a priori capable de trouver lui-même la solution. Dans tout autre cas cela ne sert à rien sauf peut être à lui retirer (très momentanément) une épine du pied.
23/06/2010, 17h59
rambc

Citation:

Envoyé par Zavonen

C'est seulement en février qu'on est févrieux, en juin on peut être à la limite fiévreux.

Preuve que je ne mens pas sur la relative inefficacité de mes neurones en ce moment...

Citation:

Envoyé par Zavonen

Un conseil, un tuyau, une aide, n'est utile pour un individu que dans la mesure où l'individu en question était a priori capable de trouver lui-même la solution. Dans tout autre cas cela ne sert à rien sauf peut être à lui retirer (très momentanément) une épine du pied.

Question subsidiaire : cet adage s'applique-t-il à ma compréhension du français ? :mouarf:
23/06/2010, 18h22
kango
salut,

je te propose une variante, plus compacte et qui évite une erreur:
Code:

1 2 3 4 def rgb(arg,*args): print (arg) for oneArg in args: print (oneArg)
en effet, ton code peut avoir un comportement inapproprié dans ce cas:
Code:

1 2 l = ['abc'] rgb(*l)
23/06/2010, 20h38
dividee

Dans certains cas vos codes peuvent être utile, mais en général n'est-ce pas mieux de laisser la responsabilité à l'appelant ?

Si celui-ci sait qu'il a une liste l = ["r","g","b"] et que la fonction prend 3 arguments, il peut facilement appeler rgb(*l). L'appelant saura toujours s'il a une liste ou 3 arguments; qu'apporte vraiment la "surcharge" ?
23/06/2010, 21h49
rambc

Citation:

Envoyé par kango

...ton code peut avoir un comportement inapproprié dans ce cas...

Il reste à faire des vérifications dans mon code, je vais le faire. Quant à l'utilisation de *, elle n'a pas lieu d'être dans mon cas comme je l'explique ci-après.

Citation:

Envoyé par dividee

Dans certains cas vos codes peuvent être utile, mais en général n'est-ce pas mieux de laisser la responsabilité à l'appelant ?

En fait, dans le cadre de mon éditeur de documents mathématiques, l'utilisateur va pouvoir utiliser un pseudo-langage de programmation proche du Python mais qui ne sera pas exactement du Python (ceci afin de répondre à pas mal de contraintes que je me suis imposé pour améliorer la prise en main de mon logiciel).
Ce pseudo-langage va être traduit ensuite en un script Python qui sera exécuté. Avec la méthode ci-dessus, je vais avoir très peu d'analyse syntaxique à faire. Avec la méthode rgb(*l), cela me demanderait de repérer les variables, leur type… Avec l'autre, c'est Python qui va s'en charger.

Voilà comment je ferais.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#! /usr/bin/env python
# PYTHON 3
 
# First try...
def rgb(*args):
    if len(args) == 1:
        args = args[0]
 
        if not isinstance(args, list):
            raise TypeError("A list of three strings, or three string arguments are expected. This is not the case.")
 
    if len(args) != 3:
        raise TypeError("Too much arguments. Three strings are expected. This is not the case.")
 
    for oneArg in args:
        if not isinstance(oneArg, str):
            raise TypeError("One of the argument is not a string.")
        print(oneArg)
    print()
 
rgb("r","g","b")
 
malist = ["r","g","b"]
rgb(malist)
 
try:
    problem = [1,"g","b"]
    rgb(*problem)
except Exception as e:
    print(str(e))
 
try:
    problem = ["r","g","b","alpha"]
    rgb(*problem)
except Exception as e:
    print(str(e))
 
try:
    problem = ['abc']
    rgb(*problem)
except Exception as e:
    print(str(e))

Bonsoir rambc,

Et pourquoi ne pas simplement utiliser type ?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
def rgb(*args):
    for oneArg in args:
        if type(oneArg) == 'dict':
        ....
        else:
            print(oneArg)
    print()
 
rgb("r","g","b")
mylist = ["r","g","b"]
rgb(mylist)
#etc...
rgb("r","g","b", mylist, mydic)

23/06/2010, 22h51
kango
isinstance et type sont à proscrire au maximum avec Python qui est un langage typé dynamiquement.

ils donnent l'illusion qu'on a réussi à résoudre un problème :D. par exemple, en mettant en testant avec isinstance si c'est une liste, ta méthode n'est plus compatible avec les tuples. et si tu rajoutes isintance pour les tuples, elle ne marchera pas avec les tableaux numpy... c'est sans fin.

l'exemple qui ne marche pas que tu donnes:
Code:

1 2 3 malist = ["r","g","b"] rgb_2(malist)
n'est pas un bon exemple. soit la fonction rgb prend un itérable en argument, soit elle prend plusieurs valeurs directement. C'est un choix à faire car on peut pas surcharger une fonction en python :)

si tu n'arrives pas à trancher, il faut passer par des arguments nommés comme suggéré par Zavonen ou laisser la responsabilité à l'appelant comme suggéré par Dividee et garder la fonction en l'état (c'est ce que je ferais pour ma part)

http://www.canonical.org/~kragen/isinstance/
23/06/2010, 23h14
rambc

Citation:

Envoyé par kango

soit la fonction rgb prend un itérable en argument, soit elle prend plusieurs valeurs directement. C'est un choix à faire car on peut pas surcharger une fonction en python :)

Relis le message que j'ai écrit juste au-dessus pour voir pourquoi je passe par la méthode peu Pythonesque ci-dessus.

Si j'étais dans un cadre purement Python, je n'aurais même pas eu l'idée de m'interroger là-dessus.

Pour le fun, un petit décorateur:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
from itertools import chain
 
def args(*types):
    """Returns a decorator which typechecks the arguments of the function,
    flattening the arguments if necessary"""
    def deco(f):
        def wrapper(*args):
            real_args = []
            ia = iter(args)
            for t in types:
                try:
                    while True:
                        a = ia.next()
                        if isinstance(a,t):
                            real_args.append(a)
                            break
                        elif isinstance(a, (tuple,list)):
                            ia = chain(iter(a),ia)
                        else:
                            raise TypeError("Expected arguments: " + str(types))
                except StopIteration:
                    raise TypeError("Not enough arguments. Expected " + str(types))
            try:
                ia.next()
            except StopIteration:
                return f(*real_args)
            raise TypeError("Too much arguments. Expected " + str(types))
        wrapper.__name__ = f.__name__
        return wrapper
    return deco
 
@args(str,str,str)
def rgb(a,b,c):
    print a,b,c

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
>>> rgb(1,2,3)
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Prog\python\test0.py", line 18, in wrapper
    raise TypeError("Expected arguments: " + str(types))
TypeError: Expected arguments: (<type 'str'>, <type 'str'>, <type 'str'>)
>>> rgb("abc")
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Prog\python\test0.py", line 20, in wrapper
    raise TypeError("Not enough arguments. Expected " + str(types))
TypeError: Not enough arguments. Expected (<type 'str'>, <type 'str'>, <type 'str'>)
>>> rgb("r","g","b")
r g b
>>> rgb(["r","g","b"])
r g b
>>> rgb(["r","g"],"b")
r g b
>>> rgb(["r","g"],[[["b"]]])
r g b
>>> rgb("r","g","b","a")
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Prog\python\test0.py", line 27, in wrapper
    raise TypeError("Too much arguments. Expected " + str(types))
TypeError: Too much arguments. Expected (<type 'str'>, <type 'str'>, <type 'str'>)

Mais bon; ce n'est pas parfait:

Code:

1
2
3
@args(list,int)
def f(l,i):
    print l[i]

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
>>> f((3,4),1)
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Prog\python\test0.py", line 18, in wrapper
    raise TypeError("Expected arguments: " + str(types))
TypeError: Expected arguments: (<type 'list'>, <type 'int'>)
>>> f([3,4],1)
4
>>> f([[3,4],1])
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Prog\python\test0.py", line 20, in wrapper
    raise TypeError("Not enough arguments. Expected " + str(types))
TypeError: Not enough arguments. Expected (<type 'list'>, <type 'int'>)
>>> f(([3,4],1))
4

[EDIT]: J'avais oublié le cas où il y a trop d'arguments

Citation:

Envoyé par rambc

Si j'étais dans un cadre purement Python, je n'aurais même pas eu l'idée de m'interroger là-dessus.

bonjour,

tu es dans un cadre purement Python :) ce n'est pas parce que ton code traite des infos qui ne sont pas du Python que tu n'y es pas.

comme ta fonction a l'air de ne vouloir fonctionner que pour 3 et exactement 3 arguments:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 def rgb(a,b,c): print a, b, c l = [1,2,3] rgb(*l) >>> 1, 2, 3 rgb(1,2,3) >>> 1, 2, 3 m = (1,2,3,4) rgb(*m) >>> TypeError: rgb() takes exactly 3 arguments (4 given) n = set(1,2) rgb(*n) >>> TypeError: rgb() takes exactly 3 arguments (2 given)
méthode qui lasse à Python la tâche de vérifier lui même le nombre d'arguments et suffisamment souple pour traiter tout type d'itérable. la responsabilité de l'appel (avec * ou pas) est à la charge de l'appelant.

24/06/2010, 10h04
rambc

Tout à fait d'accord mais...

Citation:

Envoyé par rambc

... dans le cadre de mon éditeur de documents mathématiques, l'utilisateur va pouvoir utiliser un pseudo-langage de programmation proche du Python mais qui ne sera pas exactement du Python (ceci afin de répondre à pas mal de contraintes que je me suis imposé pour améliorer la prise en main de mon logiciel).
Ce pseudo-langage va être traduit ensuite en un script Python qui sera exécuté. Avec la méthode ci-dessus, je vais avoir très peu d'analyse syntaxique à faire. Avec la méthode rgb(*l), cela me demanderait de repérer les variables, leur type… Avec l'autre, c'est Python qui va s'en charger.

C'est pour ne pas voir trop d'analyse syntaxique à faire dans le pseudo-langage que je cherchais comment implémenter la fonctionnalité qui est le sujet de ce post.
24/06/2010, 10h10
rambc

Citation:

Envoyé par dividee

Pour le fun, un petit décorateur...

Cela me plait carrément plus car je vais pouvoir appliquer ceci à différents types de fonctions et aussi à différentes souplesses d'appel. C'est super... :ccool:

J'en apprends pas mal en ce moment sur quelques points techniques dont je n'avais pas eu besoin jusqu'à présent. Comme dit l'adage... Non, en fait je suis nul en adage (voir ci-dessus pourquoi ;)).
24/06/2010, 11h24
Zavonen

Je trouve cette discussion particulièrement intéressante, parce que le sujet l'est et par la diversité et la qualité des réponses. On passe en revue les possibilités de Python qui sont nombreuses et souvent méconnues, insoupçonnées.

Citation:

dans le cadre de mon éditeur de documents mathématiques, l'utilisateur va pouvoir utiliser un pseudo-langage de programmation proche du Python mais qui ne sera pas exactement du Python (ceci afin de répondre à pas mal de contraintes que je me suis imposé pour améliorer la prise en main de mon logiciel).

Ce sujet m'intéresse, on peut en savoir un peu plus, tu as déjà publié quelque chose ?
J'avais réfléchi à ce sujet en 2008 pour arriver à la conclusion que le Python basique était si simple qu'il pouvait en l'état servir de langage de description d'algorithmes, faisant l'économie d'un pseudo-code. J'ai donc illustré un cours de matsh par des exemples en python et je donne des exos qui consistent (entre autres) à écrire de petits programmes python. Ce n'est apparemment pas ta conclusion.

Voir 40 message(s) de cette discussion en une page