Discussion :

[rambc]

Bonjour,
j'ai le code suivant :

Code :

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

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 :

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

1
2
malist = ["r","g","b"]
rgb(malist)

Est-ce possible ?

[rambc]

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 :

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

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)

[rambc]

Merci c'est super.

Voilà que je deviens schizophrène...

[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 python :

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

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

[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

[rambc]

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 donc il va falloir m'expliquer un peu cet adage...

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.

[Zavonen]

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.

[rambc]

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

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 ?

[kango]

salut,

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

Code :

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

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 :

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

1
2
l = ['abc']
rgb(*l)

[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" ?

[rambc]

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

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.

[rambc]

Voilà comment je ferais.

Code :

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

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

[PauseKawa]

Bonsoir rambc,

Et pourquoi ne pas simplement utiliser type ?

Code :

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

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)

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

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

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/

[rambc]

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.

[dividee]

Pour le fun, un petit décorateur:

Code :

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

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 :

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

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 :

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

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

Code :

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

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

[kango]

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 :

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

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.

[rambc]

Tout à fait d'accord mais...

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

[rambc]

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

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

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

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.