Gestion de plugin-in : def __init__(self, *, plugins: list=list()):

Bonjour


J'ai découvert ce tutoriel sur la gestion des plugin en python: https://alysivji.github.io/simple-plugin-system.html

Dans celui-ci, je ne comprend pas l'initialisation de la classe de gestion des plugins:

Code:

---

def __init__(self, *, plugins: list=list()):

---

Que signifie:

1. le paramètre *
2. plugins: (c'est la première fois que je découvre un : dans la déclaration d'un paramètre

Cordialement

Bonjour,

Non jamais vu cette syntaxe avec * comme paramètre sans variable, c'est sans doute une erreur, surtout quand on voit l'utilisation par la suite.

Pour plugins, par contre c'est assez connu désormais, on l'utilise pour vérifier avant exécution du code python que le type utilisé dans ta fonction est bien list. Le module mypy par exemple fait cela...

=list() indique que par défaut ta liste est vide.

Salut,

Dans la déclaration des paramètres d'une fonction on peut y trouver /, * et des annotations (:).
Pour les détails, le Python tutorial y consacre tout un chapitre (et est traduit en français).

- W

Salut,

Dans la déclaration des paramètres d'une fonction on peut y trouver /, * et des annotations (":").
Pour les détails, le Python tutorial y consacre tout un chapitre (et est traduit en français).

- W

Citation:

---

Envoyé par wiztricks

Salut,

Dans la déclaration des paramètres d'une fonction on peut y trouver /, * et des annotations (":").
Pour les détails, le Python tutorial y consacre tout un chapitre (et est traduit en français).

- W

---

Ok je connaissais pas merci, si je comprends bien * impose des arguments nommés... bah je suis pas fan ! :?

Bonjour

Citation:

---

Envoyé par fred1599

=list() indique que par défaut ta liste est vide.

---

Mouais. C'est vrai sauf que ça marche pas quand on utilise un objet mutable (liste, ensembke, dictionnaire) comme défaut. Parce que la valeur par défaut est créée à la création de la fonction et non à son appel. Donc si l'objet mute à un moment ou à un autre, il n'est plus vide par défaut pour les appels suivants.

Code:

---

1 2 3 4 5

def fct(n, l=list()): l.append(n) print(l)   for x in (1, 2, 3): fct(x)

---

Pour avoir une vraie liste vide par défaut, faut utiliser un truc immuable par défaut puis tester ce truc

Code:

---

1 2 3 4 5 6

def fct(n, l=None): if l is None; l=list() l.append(n) print(l)   for x in (1, 2, 3): fct(x)

---

Citation:

---

Envoyé par fred1599

désormais, on l'utilise pour vérifier avant exécution du code python que le type utilisé dans ta fonction est bien list

---

Oui mais en fait ça n'a aucun impact concret. C'est juste pour faciliter la lecture

Code:

---

1 2 3 4 5 6

>>> def fct(n:list): print(n, type(n)) ... >>> for x in (1, 2, 3): fct(x) 1 <class: int> 2 <class: int> 3 <class: int>

---

Pour l'instant je tente de me forcer à le mettre mais je sais pas trop si je vais continuer. Parce que parfois mes fonctions reçoivent soit un truc unique, soit une liste de trucs et que c'est pas facile de définir donc dans la signature de la fonction la nature de ce qu'elle reçoit.

Citation:

---

Envoyé par Sve@r

Oui mais en fait ça n'a aucun impact concret. C'est juste pour faciliter la lecture

---

Hello,

Comme je l'ai dis dans mon précédent message, pour que l'impact se fasse (je parle de la vérification de types me concernant), il faut utiliser mypy.

Citation:

---

Envoyé par Sve@r

Parce que la valeur par défaut est créée à la création de la fonction et non à son appel. Donc si l'objet mute à un moment ou à un autre, il n'est plus vide par défaut pour les appels suivants.

---

Je comprends, mais n'est-ce pas le comportement attendu ?

Citation:

---

Envoyé par fred1599

Comme je l'ai dis dans mon précédent message, pour que l'impact se fasse (je parle de la vérification de types me concernant), il faut utiliser mypy.

---

Ah j'avais pas noté cette précision. Je suis en train de regarder. Tyrtamos avait fait un décorateur P2 qui ressemble à ce genre de vérification. On y a travaillé en semble par MP pour le porter sous P3 (là ou *args n'est plus forcément en avant-dernier et ou co_kwonlyargcount permet de donner les paramètres situés entre "*args" et "*kwargs").

Citation:

---

Envoyé par fred1599

Je comprends, mais n'est-ce pas le comportement attendu ?

---

Je pense pas non. De mon point de vue, une valeur par défaut est une valeur qui initialise le paramètre quand on appelle une fonction sans donner d'argument à ce paramètre.
Exemple: def pow(n, p=1): return n**p.
Si j'appelle pow(1), pow(2), pow(3), je m'attends à ce que chaque appel soit traduit par "p=1" et donc récupérer des calculs indépendants ayant pour résultat 1^1, 2^1 et 3^1 et non pas un calcul de pow(2) qui serait impacté par des résidus issus du calcul de pow(1). En plus ça casserait un des paradigmes qui dit que 2 appels distincts avec la même entrée et sans autre intéraction externe doit produire le même résultat.
Mais bon, ce n'est qu'un ressenti qui me vient d'autres langages où c'est comme ça que ça se passe (ie C++, php, C#). Peut-être qu'en Python la philosophie des concepteurs sur ce point diffère un peu de la mienne. Je pense que wiztricks pourra apporter des précisions sur ce point particulier.

D'autant plus que ce comportement permet de "simuler" le static du C. Exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

def fct(eternel=[]): toto=eternel.pop() if eternel else 0 toto+=1 print(toto) eternel.append(toto) # fct()   >>> fct() 1 >>> fct() 2 >>> fct()

---

Cet exemple ne serait pas possible si le comportement de Python était tel que ce que j'attends...

Oui mais on est bien d'accord que dans son contexte de plugin, il ne modifie pas cette liste par défaut, il ne fait que là récupérer pour l'utiliser avec une autre liste ?

Ah oui oui oui, on est bien d'accord. J'ai juste donné une précision sur les dangers possibles si on commence à prendre l'habitude et qu'on utilise alors cette façon de faire dans un contexte différent qui modifierait le paramètre mutable. 8-)

Citation:

---

Envoyé par Sve@r

Ah oui oui oui, on est bien d'accord. J'ai juste donné une précision sur les dangers possibles si on commence à prendre l'habitude et qu'on utilise alors cette façon de faire dans un contexte différent qui modifierait le paramètre mutable. 8-)

---

Et tu as bien raison... il est clair que cette manière de faire (liste par défaut) n'est pas conseillée, il me semble avoir souvenirs de lire cela dans les bouquins. "Pas d'objets mutables dans les paramètres par défaut d'une fonction ! "