Pourquoi avons-nous besoin des tuples dans Python (ou n’importe quel type de données immuables) ?

Question

J'ai lu plusieurs tutoriels python (Plongée En Python), et la langue de référence sur Python.org - je ne vois pas pourquoi la langue des besoins des n-uplets.

Les Tuples ont pas de méthodes par rapport à une liste ou d'un ensemble, et si je dois convertir un tuple à un ensemble ou une liste pour être en mesure de les trier, ce qui est le point de l'utilisation d'un n-uplet en premier lieu?

L'immutabilité?

Pourquoi personne ne s'en soucie si une variable vit à un endroit différent dans la mémoire que quand il a été allouée à l'origine? Cette ensemble de l'activité de l'immuabilité en Python semble être plus souligné.

En C/C++ si j'alloue un pointeur et pour la mémoire, je n'ai pas de soins où l'adresse est situé à tant que ce n'est pas null avant que je l'utilise.

Chaque fois que j'en référence à cette variable, je n'ai pas besoin de savoir si le pointeur est toujours pointant vers l'adresse d'origine ou pas. Je viens de vérifier la nullité et de l'utiliser (ou pas).

En Python, quand je allouer une chaîne (ou tuple) affecter à x, puis modifier la chaîne, pourquoi dois-je faire si c'est l'objet original? Tant que la variable de points à mes données, c'est tout ce qui compte.

>>> x='hello'
>>> id(x)
1234567
>>> x='good bye'
>>> id(x)
5432167

x références les données que je veux, pourquoi aurait-on besoin de soins si son id est le même ou différent?

Answer 1

1. des objets immuables peut permettre importante de l'optimisation; c'est probablement pourquoi les chaînes de caractères sont aussi immuables en Java, développé séparément, mais, en même temps que Python, et juste au sujet de tout ce qui est immuable dans vraiment-les langages fonctionnels.

2. en Python, en particulier, seulement immutables peut être hashable (et, par conséquent, les membres des ensembles ou des clés dans les dictionnaires). Encore une fois, cela se permettre d'optimisation, mais beaucoup plus que juste "substantielle" (de la conception décent, les tables de hachage de stockage complètement mutable objets est un cauchemar; soit vous prenez des copies de tout dès que vous hachage, ou le cauchemar de vérifier si le hachage de l'objet a changé depuis votre dernière une référence à elle dresse sa tête hideuse).

Exemple de question d'optimisation, un intervenant dit "qu'il ne l'a jamais vu":

$ python -mtimeit '["fee", "fie", "fo", "fum"]'
1000000 loops, best of 3: 0.432 usec per loop
$ python -mtimeit '("fee", "fie", "fo", "fum")'
10000000 loops, best of 3: 0.0563 usec per loop

Excès de vitesse d'une opération par sept-huit fois pas "assez important" pour vous?! Wow, vous êtes certainement un très exigeants quand il s'agit d'affirmer que l'optimisation "substantielle"...!-)

Answer 2

Aucune des réponses ci-dessus le point le vrai problème des n-uplets vs listes, dont de nombreux Python semblent pas comprendre pleinement.

Les Tuples et les listes servent à des fins différentes. Les listes de stocker des données homogènes. Vous pouvez et devriez avoir une liste comme ceci:

["Bob", "Joe", "John", "Sam"]

La raison que c'est la bonne utilisation de listes est parce que celles-ci sont homogènes types de données, plus précisément, des noms de personnes. Mais prendre une liste comme ceci:

["Billy", "Bob", "Joe", 42]

Cette liste est une personne du nom complet, et de leur âge. Ce n'est pas un type de données. La bonne façon de stocker de l'information est soit dans un tuple, ou dans un objet. Disons que nous avons un peu :

[("Billy", "Bob", "Joe", 42), ("Robert", "", "Smith", 31)]

L'immutabilité et la mutabilité des Tuples et des Listes n'est pas la principale différence. Une liste est une liste du même type d'éléments: les fichiers, les noms, les objets. Les Tuples sont un regroupement de types d'objets différents. Ils ont des usages différents, et de nombreux codeurs Python abus des listes de ce que les tuples sont destinés.

Merci de ne pas.

---

Edit:

Je pense que ce blog explique pourquoi je pense que ce mieux que j'ai fait: http://news.e-scribe.com/397

Answer 3

si je dois convertir un tuple à un ensemble ou une liste pour être en mesure de les trier, ce qui est le point de l'utilisation d'un n-uplet en premier lieu?

Dans ce cas particulier, il n'est probablement pas un point. Ce n'est pas un problème, parce que ce n'est pas l'un des cas où vous devez envisager d'utiliser un tuple.

Comme vous le soulignez, les tuples sont immuables. Les raisons d'avoir immuable types appliquent aux tuples:

• copie de l'efficacité: plutôt que de copier un objet immuable, vous pouvez alias (lier une variable à une référence)
• comparaison de l'efficacité: lorsque vous êtes à l'aide de la copie par référence, vous pouvez comparer deux variables en comparant emplacement, plutôt que sur le contenu
• stage: vous avez besoin de stocker au plus une copie de toute valeur immuable
• il n'y a pas besoin de synchroniser l'accès à des objets immuables dans le code simultané
• const exactitude: certaines valeurs ne devraient pas être autorisés à changer. Ce (pour moi) c'est la principale raison pour immuable types.

Note qu'un Python de mise en œuvre ne peut pas utiliser toutes les fonctionnalités ci-dessus.

Les clés de dictionnaire doit être immuable, sinon la modification des propriétés d'un objet peuvent invalider les invariants de la structure de données sous-jacente. Les Tuples peuvent donc potentiellement être utilisés comme clés. C'est une conséquence de const exactitude.

Voir aussi "l'Introduction de tuples", de Plonger Dans Python.

Answer 4

Parfois, nous aimons utiliser des objets comme clés de dictionnaire

Pour ce que ça vaut, a augmenté les tuples récemment (2.6 +) et méthodes

Answer 5

J'ai toujours trouvé que d'avoir deux types distincts pour la même structure de base de données (tableaux) à une mauvaise conception, mais pas un réel problème dans la pratique. (Chaque langue a ses verrues, Python inclus, mais ce n'est pas important.)

Pourquoi personne ne s'en soucie si une variable vit à un endroit différent dans la mémoire que quand il a été allouée à l'origine? Cette ensemble de l'activité de l'immuabilité en Python semble être plus souligné.

Ce sont des choses différentes. La mutabilité n'est pas lié à l'endroit où il est stocké dans la mémoire; il signifie la farcir de points ne peut pas changer.

Des objets Python ne peut pas changer de lieu, après leur création, mutables ou pas. (Plus précisément, la valeur de l'id() ne peut pas changer--même chose dans la pratique.) Le stockage interne des objets mutables peut changer, mais c'est une face cachée de détail d'implémentation.

>>> x='hello'
>>> id(x)
1234567
>>> x='good bye'
>>> id(x)
5432167

Ce n'est pas la modification ("mutation") la variable; il est en train de créer une nouvelle variable avec le même nom et le rejet de l'ancien. Comparer à une mutation de l'opération:

>>> a = [1,2,3]
>>> id(a)
3084599212L
>>> a[1] = 5
>>> a
[1, 5, 3]
>>> id(a)
3084599212L

Comme d'autres l'ont souligné, cela permet d'utiliser les tableaux en tant que clés de dictionnaires, et autres structures de données qui ont besoin d'immuabilité.

Notez que les touches pour les dictionnaires n'ont pas à être complètement immuable. Seule la partie des il a utilisé comme une clé doit être immuable; pour certaines utilisations, c'est une distinction importante. Par exemple, vous pourriez avoir une classe représentant un utilisateur, ce qui se compare à l'égalité et d'une table de hachage par le nom d'utilisateur unique. Vous pouvez ensuite accrocher d'autres mutable données sur la classe--"l'utilisateur est connecté", etc. Puisque cela n'affecte pas l'égalité ou de la table de hachage, il est possible et parfaitement valable pour l'utiliser comme une clé dans un dictionnaire. Ce n'est pas trop souvent nécessaires en Python, je viens de l'indiquer, car plusieurs personnes ont affirmé que les clés doivent être "immuable", qui n'est que partiellement correcte. Je l'ai utilisé à de nombreuses reprises avec le C++ cartes et des ensembles.