Discussion :

[Sve@r]

Bonjour

Je m'interrogeais sur l'utilité du premier argument d'un namedtuple. Ex point=namedtuple("Point", ("x", "y")) puis p=Point(2, 3). Peut-être un peu inutilement compliqué non ?
Je veux dire que si je dois créer un tuple j'écris naturellement p=(2, 3). Je me serais attendu pour un namedtuple à faire un truc équivalent style p=namedtuple(((x, 2), (y, 3))) un peu à la manière d'un OrderedDict (qui finalement a quelques ressemblances). Alors ok on peut écrire p=namedtuple("Point", ("x", "y"))(2, 3) mais c'est ce premier paramètre "Point" qui me chagrine. Même l'OrderedDict n'a pas cette complication lui.
Donc à quoi sert concrètement ce nom qu'on passe en premier paramètre ? Quelqu'un l'a-t-il déjà utilisé ?

Merci à tous.

[wiztricks]

Salut,

Donc à quoi sert concrètement ce nom qu'on passe en premier paramètre ? Quelqu'un l'a-t-il déjà utilisé ?

Le tuple est une séquence d'objets que l'on peut accéder par un index.
Le "namedtuple" permet d'y avoir aussi un accès via un nom.
Et le paramètre sert juste à passer les noms/labels correspondant aux différents indices. (et faire que le tuple soit named).

Le premier paramètre "Point" est un détail de l'implémentation qui créé une classe avec ce nom là. Ils auraient pu choisir class Point(namedtuple(labels))... mais à coder c'est plus sportif.

- W

[fred1599]

Bonjour,

Donc à quoi sert concrètement ce nom qu'on passe en premier paramètre ? Quelqu'un l'a-t-il déjà utilisé ?

Oui dans ses début quand il est apparu pour tester.

Ça m'a permis d'éviter de créer des classes sans méthode, mais il est vrai que je l'utilise très peu, ça me paraît pas indispensable comme objet.

[Sve@r]

(et faire que le tuple soit named).

Je m'en rends compte. Je pensais que c'étaient ses items qui étaient named mais en fait pas seulement quoi.

Le premier paramètre "Point" est un détail de l'implémentation qui créé une classe avec ce nom là.

Oui c'est ça. On a bien un objet au final.

Ça m'a permis d'éviter de créer des classes sans méthode, mais il est vrai que je l'utilise très peu, ça me paraît pas indispensable comme objet.

Ca m'intéresse un peu car j'utilise pas mal la notion "d'environnement" (que je regroupe donc dans un objet dédié) et comme généralement l'environnement d'un projet c'est un truc assez invariant, je me disais que le namedtuple serait peut-être approprié pour ça.
Mais bon, quand je vois comment l'implémenter je me dis que ça ne ressemble pas vraiment à "simple is better than complex"...

Seulement (nouveau détail) ce truc qui, comme M. Jourdain, est un objet sans le savoir, possède donc des méthodes dédiées (style "index()" ou "count()"). C'est normal puisque ça se veut aussi tuple ça doit offrir les mêmes options. Mais bon, on ne peut pas changer la méthode "count()" d'un tuple tandis que celui, qui (oubliant ce détail) écrit truc=namedtuple("truc", ("count", "index"))...

[fred1599]

Ca m'intéresse un peu car j'utilise pas mal la notion "d'environnement" (que je regroupe donc dans un objet dédié) et comme généralement l'environnement d'un projet c'est un truc assez invariant, je me disais que le namedtuple serait peut-être approprié pour ça.

Ça l'est peut-être, je ne doute pas de tes choix conceptuels, par contre, au vue de sa création, je dirais que c'est pas optimal pour un code efficace.

C'est construit par un exec string, c'est pas optimum et n'a rien à voir avec le tuple standard sur la partie performance.

Code :

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

exec class_definition in namespace

birk ! Merci de m'avoir fait redécouvrir les namedtuples, je me suis intéressé au code source grâce à toi

[Bktero]

C'est même rigolo comme interrogation : "hey les gars ! pourquoi je dois donné un nom à mon tuple nommé ?"

Effectivement, ça te permet de nommer les champs mais aussi le type lui même. C'est vrai que c'est un peu dommage de devoir écrire TRUC = namedtuple("TRUC", "....") mais soit.

Personnellement, je trouve ça bien pratique, je m'en sers pour l'équivalent d'une bête structure C (avec un __str__ déjà tout fait). Quand je sens le besoin de rajouter des méthodes, je passe à une "classe normale" et mon code reste compatible.

[Sve@r]

C'est même rigolo comme interrogation : "hey les gars ! pourquoi je dois donné un nom à mon tuple nommé ?"

Ben oui. Je comprenais "namedtuple" comme "named item's tuple".

mais soit.

Mouais. Enfin quand j'écris a=dict(...) mon dict il s'appelle "a". Mon dict il est nommé "virtuellement". Là obligé d'écrire xxx=namedtuple("a", ...) puis a=xxx(...). Ou alors a=namedtuple("a", ...)(...) mais bon, c'est pas des plus "simple is better" quoi.. Mais ok, soitons zensembles.

Personnellement, je trouve ça bien pratique, je m'en sers pour l'équivalent d'une bête structure C (avec un __str__ déjà tout fait).

Et tu n'utilises pas les possibilités du tuple (l'indexation, le slicing, l'itérativité) ?

Quand je sens le besoin de rajouter des méthodes, je passe à une "classe normale" et mon code reste compatible.

Ah oui je vois pourquoi. Ou alors tu rajoutes __getitem__() et __iter__()

[danielhagnoul]

@Pyramidev avait raison, après quelques tests de manipulation de l'un et de l'autre, j'ai un nette préférence pour les dataclasses : https://docs.python.org/3/library/dataclasses.html

[Bktero]

À partir de Python 3.7, on a les data classes

J'ai moi aussi fait quelques essais et c'est carrément ce qu'il me fallait ! Jusqu'à maintenant j'utilisais des namedtuples, je vais maintenant utiliser des dataclasses pour ce cas particulier ! Merci !