python: liste vs tuple, quand les utiliser?

Il existe une forte culture de tuples pour les collections hétérogènes, similaire à celle utilisée pour les collections C, et les listes étant destinées à des collections homogènes, similaires à celles utilisées pour les tableaux. Mais je n’ai jamais tout à fait raison avec le problème de la mutabilité mentionné dans les autres réponses. La mutabilité a des dents (vous ne pouvez pas changer un tuple), alors que l’homogénéité n’est pas appliquée, et il semble donc y avoir une distinction beaucoup moins intéressante.

Les tuples sont de taille fixe dans la nature alors que les listes sont dynamics.
En d’autres termes, un tuple est immuable alors qu’une list est mutable .

1. Vous ne pouvez pas append d’éléments à un tuple. Les tuples n’ont pas de méthode d’ajout ou d’extension.
2. Vous ne pouvez pas supprimer des éléments d’un tuple. Les tuples n’ont pas de méthode supprimer ou pop.
3. Vous pouvez trouver des éléments dans un tuple, car cela ne change pas le tuple.
4. Vous pouvez également utiliser l’opérateur in pour vérifier si un élément existe dans le tuple.

• Les tuples sont plus rapides que les listes. Si vous définissez un ensemble constant de valeurs et que tout ce que vous allez faire, c’est l’itérer, utilisez un tuple au lieu d’une liste.

• Cela rend votre code plus sûr si vous protégez en écriture des données qui n’ont pas besoin d’être modifiées. Utiliser un tuple au lieu d’une liste, c’est comme avoir une affirmation implicite que ces données sont constantes, et qu’une pensée spéciale (et une fonction spécifique) est nécessaire pour remplacer cela.

• Certains tuples peuvent être utilisés comme clés de dictionnaire (en particulier, les tuples qui contiennent des valeurs immuables telles que des chaînes, des nombres et d’autres tuples). Les listes ne peuvent jamais être utilisées comme des clés de dictionnaire, car les listes ne sont pas immuables.

Source: Plongez dans Python 3

Je crois (et je ne connais pas bien Python) que la principale différence est qu’un tuple est immuable (il ne peut pas être changé après l’affectation) et qu’une liste est modifiable (vous pouvez append, modifier, soustraire, etc. ).

Donc, j’ai tendance à faire mes tuples des choses qui ne devraient pas changer après l’affectation et ma liste des choses qui peuvent.

Doit-il être mutable? Utilisez une liste. Ne doit-il pas être mutable? Utilisez un tuple.

Sinon, c’est une question de choix.

Pour les collections d’objects hétérogènes (comme une adresse divisée en nom, rue, ville, état et zip), je préfère utiliser un tuple. Ils peuvent toujours être facilement promus en tuples nommés .

De même, si la collection doit être répétée, je préfère une liste. Si c’est juste un conteneur pour contenir plusieurs objects, je préfère un tuple.

La première chose à décider est de savoir si la structure de données doit être mutable ou non. Comme cela a été mentionné, les listes sont mutables, les tuples ne le sont pas. Cela signifie également que les tuples peuvent être utilisés pour les clés de dictionnaire, où les listes ne peuvent pas.

D’après mon expérience, les tuples sont généralement utilisés là où l’ordre et la position sont significatifs et cohérents. Par exemple, en créant une structure de données pour choisir votre propre jeu d’aventure, j’ai choisi d’utiliser des tuples au lieu de listes car la position dans le tuple était significative. Voici un exemple de cette structure de données:

 pages = {'foyer': {'text' : "some text", 'choices' : [('open the door', 'rainbow'), ('go left into the kitchen', 'bottomless pit'), ('stay put','foyer2')]},} 

La première position dans le tuple est le choix affiché pour l’utilisateur lors de la lecture du jeu et la deuxième position est la clé de la page vers laquelle le choix est effectué et ceci est cohérent pour toutes les pages.

Les tuples sont également plus efficaces en mémoire que les listes, même si je ne suis pas certain quand cet avantage deviendra apparent.

Consultez également les chapitres sur les listes et les tuples dans Think Python .

Mais si je suis celui qui conçoit l’API et choisit les types de données, quelles sont les directives?

Pour les parameters d’entrée, il est préférable d’accepter l’interface la plus générique qui fait ce dont vous avez besoin. Il s’agit rarement d’un tuple ou d’une liste – le plus souvent c’est une séquence, tranchante ou même itérable. Le typage en canard de Python est généralement gratuit, à moins que vous ne vérifiiez explicitement les types d’entrée. Ne le faites pas à moins que ce soit absolument inévitable.

Pour les données que vous produisez (parameters de sortie), renvoyez simplement ce qui vous convient le mieux, par exemple, retournez le type de données que vous conservez ou quelle que soit la fonction de votre assistant.

Une chose à garder à l’esprit est d’éviter de retourner une liste (ou tout autre mutable) faisant partie de votre état, par exemple

 class ThingsKeeper def __init__(self): self.__things = [] def things(self): return self.__things #outside objects can now modify your state def safer(self): return self.__things[:] #it's copy-on-write, shouldn't hurt performance 

Un avantage mineur mais notable d’une liste sur un tuple est que les listes ont tendance à être légèrement plus portables. Les outils standard sont moins susceptibles de prendre en charge les tuples. JSON, par exemple, n’a pas de type de tuple. YAML le fait, mais sa syntaxe est moche par rapport à la syntaxe de la liste, ce qui est plutôt bien.

Dans ces cas, vous pouvez souhaiter utiliser un tuple en interne, puis le convertir en liste dans le cadre d’un processus d’exportation. Alternativement, vous pouvez vouloir utiliser des listes partout pour la cohérence.