L’opérateur splat (l’étoile: *) en Python
L’utilisation du signe étoile (*, dit opérateur “splat”) en Python est très simple, mais certains cas sont peu intuitifs. Les nouveaux venus ont souvent besoin d’un peu plus d’explications que ce que donne la doc. Les utilisateurs d’autres langages sont généralement déroutés car ils sont habitués certaines fonctionnalités qu’on ne retrouvent pas en Python.
Ce que * ne permet pas de faire
Il n’y a pas de pointeurs en Python, et les passages par référence sont automatiques. Du coup :
mon_objet = MaClasse() mon_pointeur = *mon_objet ma_valeur = **mon_pointeur
N’existe pas en Python. On ne peut pas récupérer un pointeur. On ne peut pas choisir si l’on passe une variable par valeur ou par référence. Tout est automatique et transparent.
Les usages basiques de *
La multiplication et la puissance fonctionnent comme on l’attend :
>>> print(2*3) # multiplier 2 par 3 6 >>> print(2**3) # élever 2 à la puissance 3 8
Mais déjà, Python se démarque du lot car l’opérateur * est surchargé par défaut, et peut s’appliquer aux chaînes de caractères et aux listes. Pour les chaînes, c’est simple :
>>> print("a" * 3) # on peut multiplier une chaîne par un nombre, et cela donne une chaîne aaa >>> print("a" ** 3) # ça ne marche pas avec les puissances TypeError: unsupported operand type(s) for ** or pow(): 'str' and 'int'
Pour les listes, c’est plus subtile. Une liste de nombres se multiplie sans y penser :
>>> l = [0, 1, 3] >>> print(l * 2) # on peut multiplier une liste par un nombre, cela donne une liste [0, 1, 3, 0, 1, 3] >>> print(l ** 2) # ça ne marche pas avec les puissances TypeError: unsupported operand type(s) for ** or pow(): 'list' and 'int'
En revanche, multiplier une liste d’objets modifiables ne fait que répéter la référence vers cet objet :
>>> l = [{}] # on fait une liste contenant un dictionnaire >>> dicos = l * 3 # on peut multiplier une liste par un nombre, cela donne une liste >>> print(dicos) [{}, {}, {}]
On a l’impression que le comportement est le même que précédemment,
>>> d = dicos[0] # on récupère ce qu'on croit être le premier dictionnaire >>> d["Nouvelle cle"] = "Nouvelle valeur" # on le modifie >>> print(dicos) # afficher la liste montre que les 3 dictionnaires sont en fait un seul et même objet [{'Nouvelle cle': 'Nouvelle valeur'}, {'Nouvelle cle': 'Nouvelle valeur'}, {'Nouvelle cle': 'Nouvelle valeur'}]
Unpacking
Python intègre une fonctionnalité, l’unpacking, qui permet de prendre chaque élément d’une séquence et de les attribuer à des variables distinctes, d’un seul coup. C’est un raccourcis très pratique :
>>> drapeau = ("bleu", "blanc", "rouge") # ici on utilise un tuple, mais ça marche avec les listes >>> premiere_couleur = drapeau[0] >>> deuxieme_couleur = drapeau[1] >>> troisieme_couleur = drapeau[2] >>> print(premiere_couleur) 'bleu' >>> print(deuxieme_couleur) 'blanc' >>> print(troisieme_couleur) 'rouge' >>> couleur1, couleur2, couleur3 = drapeau # la même opération, en une ligne grace à l'unpacking >>> print(couleur1) 'bleu' >>> print(couleur2) 'blanc' >>> print(couleur3) 'rouge'
Vous n’avez rien à faire, l’unpacking est automatique : il suffit de mettre à gauche du signe = le même nombre de variables qu’il y a d’éléments dans la séquence à droite du signe =. Dans le cas contraire, Python râle :
>>> un, deux = drapeau ValueError: too many values to unpack >>> un, deux, trois, quatre = drapeau ValueError: need more than 3 values to unpack
Quel rapport avec * ? Et bien il permet de forcer l’unpacking dans le cas où c’est ambigüe. Faisons une petite fonction de test qui ne
fait qu’afficher chacun de ses paramètres :
>>> def afficher_trois_elements(elem1, elem2=None, elem3=None): ... print(elem1) ... print(elem2) ... print(elem3) ... ... >>> afficher_trois_elements(drapeau) ('bleu', 'blanc', 'rouge') None None
Passer drapeau affiche logiquement le tuple comme premier paramètre, et ensuite les valeurs par défaut du premier et du second paramètre.
En utilisant *, nous pouvons forcer l’unpacking de telle sorte que les valeurs du tuple soient passées individuellement comme autant de paramètres :
>>> afficher_trois_elements(*drapeau) bleu blanc rouge
Très pratique quand vous utilisez une collection tout au long du programme pour vous éviter de sans cesse trainer des variables intermédiaires. D’autant que ça marche combiné aux slices :
>>> l = [1, 2, 3, "element que l'on ne veut pas"] >>> afficher_trois_elements(*l[:-1]) 1 2 3
Encore mieux, on peut utiliser ** pour forcer l’unpacking des dictionnaires. Les valeurs du dictionnaires deviennent les valeurs des paramètres, mais cette association se fait par nom : chaque clé du dictionnaire doit correspondre à un nom de paramètre. Ainsi :
>>> elements = {"elem1": "eau", "elem2": "feu", "elem3": "air"} # les clés ont le bon nom >>> afficher_trois_elements(**elements) eau feu air
Si une clé ne possède pas le nom adéquat, tout plante :
>>> elements = {"elem1": "eau", "elem2": "feu", "rien_a_voir": "air"} >>> afficher_trois_elements(**elements) TypeError: afficher_trois_elements() got an unexpected keyword argument 'rien_a_voir'
Une autre erreur courante est d’utiliser * avec un dictionnaire. Dans ce cas l’unpacking fonctionne, mais comme itérer sur une dictionnaire donne une liste de clés, c’est comme si vous passiez une liste en paramètres contenant les clés :
>>> elements = {"elem1": "eau", "elem2": "feu", "elem3";: "air"} >>> afficher_trois_elements(*elements) elem2 elem3 elem1
Si vous donnez moins de valeurs qu’il n’y a de paramètres, Python remplit tout ce qu’il peut :
>>> afficher_trois_elements(*drapeau[:-1]) bleu blanc None >>> elements = {"elem1": "eau"} >>> afficher_trois_elements(**elements) eau None None
Dans le cas inverse – si i il y a plus d’élements que de paramètres – Python vous envoie vous brosser :
>>> forces = ("rouge", "bleu", "jaune", "rose", "vert") >>> afficher_trois_elements(*forces) TypeError: afficher_trois_elements() takes at most 3 arguments (5 given)
Paramétrage dynamique
Il est parfois pratique de définir une fonction qui accepte un nombre infini d’arguments. Exemple bidon, une fonction qui multiplie ses arguments entre eux :
>>> def multiply(a, b): ... return a * b # attention, là on utilise <code>*</code> pour multiplier, ne cherchez rien de compliqué ;-) ... >>> print(multiply(2, 3)) 6
Bien sûr, si on veut rajouter un troisième paramètre, il faut la réécrire. Pareil pour un quatrième. Finalement, on finit par demander de passer une liste pour permettre un nombre arbitraire :
>>> def multiply(elements_a_multiplier): ... res = 1 ... for i in elements_a_multiplier: ... res = res * i ... return res ... >>> multiply((1, 2, 3, 4)) 24
Et bien sachez qu’il existe une autre possibilité, autoriser le passage d’une infinité de paramètres ! Cela se fait bien sur avec *.
>>> def multiply(*tous_les_elements): # on ne change pas grand chose, on rajoute juste <code>*</code> ... res = 1 ... for i in tous_les_elements): ... res = res * i ... return res ... >>> multiply(1, 2, 3) # mais plus besoin d'une séquence ! 26 >>> multiply(1, 2, 3, 4, 5) 120
Comment ça marche ? C’est simple, tous les arguments sont automatiquement stockés dans une liste, et cette liste est le paramètre que l’on a désigné par *.
Ce système très puissant peut être utilisé conjointement avec des paramètres normaux :
>>>def afficher(elem1, elem2, *elemx): ... print(elem1) ... print(elem2) ... for e in elemx: ... print("(*) %s" % e) … >>> afficher("Toi", "Moi", "Luke", "Anakin", "Obi Wan", "Robert") Toi Moi (*) Luke (*) Anakin (*) Obi Wan (*) Robert
La seule condition est de mettre * sur un paramètre situé après tous les autres. * est toujours en dernier, et il n’apparait qu’une seule fois. Enfin, il existe une convention pour le nom de cet argument : *args.
Bonne nouvelle, on peut utiliser aussi **. Comme on peut s’y attendre, il permet de récupérer aussi une infinité de paramètres, mais sous forme de dictionnaire. Cela signifie qu’il ne récupère que les paramètres nommés :
>>> def afficher_recette(recette, **ingredients): # ingrédients sera un dictionnaire ... print(recette) ... for ingredient in ingredients.iteritems(): ... print " - %s: %s" % ingredient ... >>> afficher_recette("moukraines à la glaviouse", ... creme="trop", # on doit donner le nom de ce paramètre ... moukraines= "suffisamment", ... glaviouse="si disponible") # mais l'ordre des paramètres importe peu moukraines à la glaviouse - glaviouse : si disponible - creme : trop - moukraines : suffisamment
Il faut également mettre ** après tous les autres arguments. La convention pour nommer ce paramètre est **kwargs, pour « keyword arguments ». Enfin, on peut mélanger tout ça d’un coup :
>>> def affichage_hybride(parametre_normal, ... parametre_avec_default="valeur par défaut", ... *args, ... **kwargs): ... print(parametre_normal) ... print(parametre_avec_default) ... print(args) ... print(kwargs) ... >>> affichage_hybride("param1", "param2", "infini1", "infini2", kwinfini1=1, kwinfini2=2) param1 param2 ('infini1', 'infini2') {'kwinfini1': 1, 'kwinfini2': 2}
On doit absolument mettre les paramètres dans cet ordre :
- paramètres normaux et obligatoires;
- paramètres normaux facultatifs (valeur par défaut);
- paramètres dynamiques;
- paramètres dynamiques nommés.
En plus, cela permet en effet de faire jouer les valeurs par défaut de manière très souple :
>>> affichage_hybride("param tout seul") param tout seul valeur par défaut () {}
Si vous vous sentez à l’aise avec tout ça, vous pouvez mélanger plusieurs usages de * d’un coup. Je vous laisse donc en guise de conclusion un petit combo qui utilise un code précédent :
>>> def multiply(*args): ... res = 1 ... for i in elements_a_multiplier: ... res = res * i ... return res ... >>> print(multiply(*([2]*6)) == 2**6) True
No related posts.
On adooooore les bitcoins :
Joli inventaire :)
Mes 2 cents: on réécrira avantageusement
res = res * i
par
res *= i
Peut-être une typo dans la dernière partie relative à l’unpacking? Le dernier élément du dictionnaire
elementsest attribué à une clef déjà présente,elem3; il serait peut-être préférable de le mapper à une nouvelle clef, par ex.elem4?>>> elements = {"elem1": "eau", "elem2": "feu", "elem3": "air", "elem4": "terre"}Du coup, Python (2.7.3 et 3.2.3) râle aussi avec les éléments surnuméraires d’un dico:
Oui, c’est une typo et une erreur de logique de ma part. Merci de l’avoir signalé.
Petite précision : si le dictionnaire passé en guise de **kw contient une clef qui correspond déjà à un paramètre passé en argument, Python va râler.
Ca peut arriver quand on utilise des arguments nommés dans une fonction, et plus tard on remplit le dictionnaire dynamiquement.
Bonjour,
petit message d’introduction, car c’est le premier commentaire que je vous envoie : “j’aime bien votre blog”.
Je sais que c’est pas le sujet de cet article, mais une petite fonction reduce, au lieu de la boucle qui multiplie, c’est plus classe, et plus “pythoniesque”.
A la place de :
res = 1
for i in elements_a_multiplier:
res = res * i
return res
On peut mettre juste une ligne :
return reduce(lambda x, y: x * y, elements_a_multiplier)
Mais je suppose que vous connaissiez déjà. Et que vous ne l’avez pas mis pour pas tout embrouiller.
Et sinon, le “*”, on peut aussi le mettre dans les import. Mais ça c’est le mal absolu, il paraît.
:-) Vous avez tout compris.
Cela dit je n’irai pas jusqu’à dire que “import *” c’est le mal, mais il y a très peu de cas ou les bénéfices de son usage dépassent les inconvénients à long terme.
Je suis formateur, et je ne l’enseigne pas, même à des professionels. Je l’explique uniquement si on me pose la question. En devenant plus chevroné, on apprend tout seul à les rares situations ou c’est pertinent.
Dans le reste des cas, une petites astuce pour les imports longs: on peut aller à la ligne en utilisant des parenthèses. Ex:
y a des mecs qui arrives par:
c’est quoi **kwargs sous python
Sur d’autres articles du blog. C’est l’article de cette page qui répond à cette question. J’espère que ce petit com donneras un indice à ceux qui cherchent ça.
J’ai l’impression que le paragraphe “On doit absolument mettre les paramètres dans cet ordre :” est incomplet.
Dès qu’on mets un ou des paramètres normaux facultatifs, on ne peut plus mettre *args après. Ca lève un SyntaxError: non-keyword arg after keyword arg
On est alors obligé de récupérer un dictionnaire (kwarg).
En résumé :
fun(a, b, c)
fun(a, b=1, c=2)
fun(a, *arg)
fun(a, b=1, **arg)
sont valides alors que
fun(a, b=1, *arg)
SyntaxError: non-keyword arg after keyword arg
Dites moi si un truc m’a échappé.
O_o
Marche parfaitement pour moi.
Quelle est votre version de Python ?
Voici un snippet : http://pastebin.com/JNp0mj3y
J’utilise python 3.2 (et 2.7 testé)
Merci.
Dans le snippet fournit, la seule erreur est à la dernière ligne:
Python n’autorise pas
4242aprèsb=42. Ca n’est pas lié à*argsou**kwargs, c’est comme ça pour toutes les fonctions.Tout à fait. Donc, la signature suivante
fun3(a, b=1, *arg)n’a pas vraiment de sens puisque *arg ne pourra rien recevoir ou bien il faut laisser b à la valeur par défaut si on veut passer des choses à *arg.Je ne vois pas comment on peut passer un b différent et des valeurs à *arg…
La signature dit:
- j’ai un seul argument obligatoire;
- j’ai un argument facultatif dont la valeur par défaut est 1;
- j’accepte un nombre infini d’arguments.
On peut donc appeler fun3 ainsi:
- fun3(1)
- fun3(1, 2)
- fun3(1, 2, 3, …)
C’est un signature tout à fait sensée, et souple pour une fonction: elle assure un minimum de deux arguments, force l’utilisateur à décider le premier argument et autorise l’infini.
Merci les mecs, j’ai enfin compris l’utilité de *args et **kwargs!
Jusqu’à maintenant, je n’étais tombé que sur des explications plus ou moins bidons, là au moins, c’est clair!
De rien mon cher syl
ENFIN une explication claire, le **kwargs et le *args à la portée du commun des mortels !
Merci pour ce site, vous êtes en train de refaire mon éducation python.
Une petite précision: l’unpacking ne marche que pour unpacker une liste dans les paramètres d’une fonction.
On ne peut pas l’utiliser pour unpacker une liste dans une assignation de variable.
exemple :
couleurs = [jaune, blanc, bleu]
plus_de_couleurs = [rouge, *couleurs]
Il est impossible d’exécuter ce code !
Tout du moins en Jython. Je n’ai pas vérifié en python.
On ne peut pas unpacker une liste dans une liste.
Ce code peut néanmoins être réécrit ainsi:
ok, cool.
merci pour les explications, et merci pour le premier commentaire, ça décomplexe vachement! Je me sens très proche de Max pour le coup (mais c’est pas vraiment une surprise).