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

[Pyramidev]

Salut,

À partir de Python 3.7, on a les data classes qui concurrencent collections.namedtuple.
Si on veut créer une data class dont tous les champs sont immuables, on peut utiliser le décorateur dataclasses.dataclass(frozen=False).
Personnellement, je travaille en Python 3.7 (pas encore Python 3.8) et je n'utilise jamais collections.namedtuple. J'utilise toujours les data classes à la place.
La PEP 557, qui introduit les data classes, contient une section Why not just use namedtuple? qui met en évidence certaines différences.

[Bktero]

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

Oula ! Quand tu fais Point = namedtuple("Point", "x, y"), tu crées une classe, pas une variable !

Code :

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

1
2
3
4
5
6
>>> from collections import namedtuple
>>> Point = namedtuple("Point", "x, y")
>>> print(Point)
<class '__main__.Point'>
>>> print(type(Point))
<type 'type'>

Du coup, une fois que tu as ta classe, il faut bien créer une variable de ce type :

Code :

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

1
2
3
4
5
>>> p = Point(2,3)
>>> print(p)
Point(x=2, y=3)
>>> print(type(p))
<class '__main__.Point'>

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

Euh... Non : /

Salut,

À partir de Python 3.7, on a les data classes qui concurrencent collections.namedtuple.
Si on veut créer une data class dont tous les champs sont immuables, on peut utiliser le décorateur dataclasses.dataclass(frozen=False).
Personnellement, je travaille en Python 3.7 (pas encore Python 3.8) et je n'utilise jamais collections.namedtuple. J'utilise toujours les data classes à la place.
La PEP 557, qui introduit les data classes, contient une section Why not just use namedtuple? qui met en évidence certaines différences.

Ca semble très intéressant je vais aller voir ça de plus prêt ! Merci !

[Sve@r]

Oula ! Quand tu fais Point = namedtuple("Point", "x, y"), tu crées une classe, pas une variable !
Du coup, une fois que tu as ta classe, il faut bien créer une variable de ce type p = Point(2,3)

Exactement ce que j'ai dit au début. Inutilement compliqué. Parce que concrètement ta classe, si tu ne t'en sers qu'une fois, elle sert alors à pas grand chose => p=namedtuple("Point", "x, y")(2, 3).
Pour l'OrderedDict c'est beaucoup plus simple => p = OrderedDict((("x", 2), ("y", 3))). C'était pas naturel d'espérer un truc équivalent pour le namedtuple (ex p = namedtuple((("x", 2), ("y", 3)))) ?

[Bktero]

Ben là monsieur, c'est le principe même du truc :

namedtuple()

factory function for creating tuple subclasses with named fields

C'est un peu comme si tu disais "mais c'est pas un peu lourd d'avoir des clés dans dictionnaire, je peux faire pareil avec un tuple sans me faire chier". Le but de namedtuple() est de créer un nouveau type. Ce n'est pas un conteneur mais un créateur de types de conteneurs.

Au contraire de :

OrderedDict

dict subclass that remembers the order entries were added

En gros, tu voudrais un hybride entre un dict et un tuple ? Qu'est ce qui ne te convient dans le dict qui t'a poussé vers namedtuple ?

[Sve@r]

Le but de namedtuple() est de créer un nouveau type. Ce n'est pas un conteneur mais un créateur de types de conteneurs.

Hé oui. D'où ma première question qui était "qu'en pensez-vous"...

En gros, tu voudrais un hybride entre un dict et un tuple ?

Même pas. J'ai évoqué l'OrderedDict juste comme contre-exemple par rapport à sa syntaxe.

Qu'est ce qui ne te convient dans le dict qui t'a poussé vers namedtuple ?

Pour l'instant rien. J'utilise l'OrderedDict de façon assez poussée et en plus je le trouve plus intéressant. Par exemple on peut placer une clef dans une variable "var" puis demander p[var] ce que ne permet pas le tuple. Comme je l'ai dit au début, "j'envisageais" éventuellement de l'utiliser. Mais quand je vois (en dehors de sa syntaxe) fred1599 dire que les perfos c'est pas terrible et Pyramidev nous montrer son successeur, je me dis que ça vaut vraiment pas le coup.

[fred1599]

Mais quand je vois (en dehors de sa syntaxe) fred1599 dire que les perfos c'est pas terrible

Oui, seulement lors de la création de l'objet, après, c'est un tuple... Ce qui est dommage, c'est justement que le principal avantage en dehors de la partie concept (choix entre objet mutable ou immutable) pour un tuple est sa création ultra performante et une consommation mémoire extrêmement faible. Avec les namedtuple on lui retire ses deux vrais points forts.

Seulement à moins de créer énormément de namedtuple, il n'y a pas de réel restriction à l'utiliser. L'avantage pourrait être la clarté dans un code où l'on souhaite privilégier la POO par exemple et comme dis plus haut, un peu à l'équivalent d'un struct en C.

Rien que pour 10000 itérations, on voit une différence très significative,

Pour les namedtuple: 2.6065110000000002
Pour les tuple: 0.0017840000000002298

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
from time import clockfrom collections import namedtuple
 
def test(f):
    start = clock()
    for _ in range(10000):
        tup = f()
    return clock() - start
 
def f1():
    return namedtuple('Point', [])
 
def f2():
    return tuple()
 
 
print("Pour les namedtuple: {}".format(test(f1)))
print("Pour les tuple: {}".format(test(f2)))

On voit bien que ces deux objets n'ont pas le même but...

[wiztricks]

Salut,

On voit bien que ces deux objets n'ont pas le même but...

Déjà namedtuple retourne une "class" pas une instance.
Si on veut "comparer", il faudrait avoir:

Code :

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

1
2
3
Point = namedtuple('Point', 'x y')
def f1():
    return Point(1, 2)

Pour le reste, c'est une histoire de représentation d'un tableau M x N.

Est-ce qu'on dit c'est M colonnes à N items et dans ce cas .count, .index sont applicables à chacune des colonnes/séquences ou est-ce qu'on dit que c'est N lignes d'enregistrements à M colonnes?

Dans le 2nd cas, est ce qu'on va relier les M éléments d'une ligne avec une glue de type "class" ou je vais avoir des attributs explicites ou via "liste" ou "tuple" où n'ayant que des index je vais devoir faire le mapping "nom" <=> index "à la main"?
Créer un namedtuple est juste une solution "entre les deux". Plus facile à créer qu'une "class" et préservation de l'ordre dans items de la ligne.

Personnellement, je m'en sers beaucoup pour représenter les lignes d'un fichier, les relations d'une table,... Et si plus tard, une "class" devient plus adaptée, il y a moins de code à revoir.

- W

[fred1599]

Salut,



Déjà namedtuple retourne une "class" pas une instance.
Si on veut "comparer", il faudrait avoir:

Code :

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

1
2
3
Point = namedtuple('Point', 'x y')
def f1():
    return Point(1, 2)

Ah oui, ça reste tout de même 8 fois plus lent en moyenne... mais n'a rien à voir avec la différence précédente. Sorry !

[wiztricks]

Ah oui, ça reste tout de même 8 fois plus lent en moyenne... mais n'a rien à voir avec la différence précédente. Sorry !

Oui mais avec Python (et dans ce cas particulier) ce qu'on cherche à "optimiser" c'est le temps passé à relire le code.

- W

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