Pandas: Demande de DataFrame.to_tsv() pour lire le texte délimité par des tabulations

En plus d'être simplement to_csv(sep='\t') , une fonction to_tsv devrait envisager de changer les guillemets par défaut, car les guillemets sont moins nécessaires pour les fichiers tsv.

L'API pandas est déjà encombrée d'un excès de méthodes pratiques rarement utilisées. Je ne pense vraiment pas que l'ajout d'un autre soit une bonne idée.

Je suis d'accord avec @shoyer ici. Toutes les fonctionnalités sont là pour le faire dans to_csv , et étant donné que nous avons déjà de nombreuses méthodes, je pense que la raison d'en ajouter une nouvelle devrait être plus forte que de pouvoir fournir d'autres valeurs par défaut.

Je ferme ceci (nous avons trop de problèmes ouverts ..), mais la discussion peut certainement continuer si nécessaire.

+1. En tant que praticien, j'apprécierais fortement le sucre to_tab .

Je pense que la raison d'en ajouter un nouveau devrait être plus forte que de pouvoir fournir d'autres valeurs par défaut.

La commodité de l'OMI est une justification valable (les gens ont tendance à écrire de nombreux fichiers texte, donc to_csv doit constamment être complété par des paramètres).

Cependant, ma principale motivation est un dédain pour le format CSV. Cela me fait mal de voir des gens utiliser encore CSV sur TSV. De toute évidence, le support Excel / base de données a un rôle à jouer. Mais un projet comme pandas devrait s'efforcer de rendre les meilleures pratiques les plus faciles à mettre en œuvre.

bien que ce ne soit pas un problème majeur pour moi actuellement, csv est centré sur la représentation des États-Unis / du Commonwealth et n'est pas conscient de la situation internationale. Avec toute la philosophie Pythonic d'acceptation de l'UTF et de l'internationalisation, les tabulations séparées doivent être préférées à csv / point-virgule-sv.

Bien que je puisse comprendre le sentiment mis en avant par @shoyer , je suis d'accord avec @dhimmel. D'après mon expérience, TSV est beaucoup plus un format standard pour l'analyse de données que CSV. Il existe de nombreux cas d'utilisation où le format TSV est une exigence, alors que je n'en connais aucun pour le format CSV (il y a quelques exemples d'utilisations courantes ici ). TSV a également l'avantage que le texte brut est facilement lisible et évite les problèmes de citation mentionnés par @dhimmel.

Je ne suis que légèrement opposé à l'ajout to_tsv . D'après mon expérience (aux États-Unis), CSV est plus courant que TSV (au moins au nom du format de fichier), mais seulement légèrement. La principale vertu to_tsv est que le nom indique instantanément ce qu'il fait.

CSV et TSV sont tous deux bien pris en charge et largement utilisés en science des données. CSV est plus un format hérité, donc de nombreux projets orientés vers l'arrière sont par défaut CSV. Cependant, je pense que les projets axés sur l'avenir devraient utiliser par défaut TSV, car c'est mieux pour la science des données. Puisqu'il n'y a pas de fonction de sortie to_text_delimited_file par défaut dans les pandas, to_csv est la valeur par défaut de facto. Étant donné que la plupart des utilisateurs ne se soucient pas assez de spécifier manuellement sep='\t' , les pandas contribuent à la prévalence des CSV par rapport aux TSV et retardent l'essor du format supérieur.

Veuillez excuser mon ignorance à ce sujet, mais en plus d'être plus facile à lire en tant qu'humain, si et seulement si les en-têtes de colonne ont à peu près les mêmes caractères que leurs données correspondantes, ce qui n'est pas toujours le cas, quels avantages TSV offre-t-il par rapport à CSV ? Honnêtement, curieux de savoir s'il existe une différence de performances entre les deux, j'utilise TSV en ce moment, mais honnêtement, uniquement parce que les fichiers de données avec lesquels je travaille sont arrivés dans ce format, je les ai donc laissés dans le même format.

Quels avantages le TSV offre-t-il par rapport au CSV ?

Les onglets @ Starkiller4011 sont un séparateur plus naturel pour les données en colonnes. Ils nécessitent moins de guillemets, car les valeurs contiennent rarement des tabulations mais contiennent souvent des virgules.

Honnêtement curieux de savoir s'il y a une différence de performance entre les deux

Je m'attendrais à ce que la différence de performances soit insignifiante. Cependant, comme la plupart des choses en science des données, le véritable type de performance qui compte est l'efficacité du programmeur. Et je pense que les TSV sont plus agréables à utiliser que les CSV.

Tout le monde n'est pas d'accord pour dire que la séparation des tabulations est supérieure à csv - moi non, par exemple.

En tant que programmeurs Python, nous savons que les espaces blancs ne sont pas toujours conservés dans différentes opérations, comme le copier-coller. Ceux d'entre nous qui répondent à beaucoup de questions sur SO, par exemple, doivent régulièrement utiliser sep="\s\s+" pour analyser le texte que les gens ont vidé dans un format séparé par des espaces, et nous devons espérer qu'ils ont mis suffisamment d'espaces entre les colonnes pour que cela fonctionne. S'ils utilisaient des virgules, des points-virgules, des pipes ou quelque chose comme ça, ce ne serait pas un problème. (Et je viens de penser aux carats, qui étaient utilisés assez largement dans certains domaines.)

Si nous voulons ajouter un alias to_tsv pour rendre certaines personnes plus heureuses, d'accord. Mais ne prétendons pas que TSV n'a pas ses propres maux de tête lorsque vous travaillez avec, et le seul avantage auquel je peux penser est moins de citations.

Je pense que cela vaut la peine de prendre du recul et de reconnaître qu'une fonction comme to_csv est un peu idiote, la solution devrait être une fonction to_table plus générique qui nécessite la spécification d'un délimiteur, et qui to_csv n'est qu'un emballage pratique. R a cette fonctionnalité dans sa fonction write.table() , ce qui est plus logique.

Pour mémoire, je pense que CSV et TSV et des formats acceptables et bons. Ils doivent être soutenus tous les deux. @dsm054 apporte des avantages convaincants aux délimiteurs non blancs.

Un problème plus important à mon avis est d'utiliser l'extension .csv sans discernement (par exemple, en se référant aux TSV). Voir la discussion sur https://github.com/pandas-dev/pandas/pull/14587. Je suis d'accord avec @stevekm que to_table devrait être une fonction générique où vous devriez spécifier votre délimiteur, tandis que to_csv ou to_tsv devrait se concentrer sur ces normes. Aborder cela dans une rétrocompatibilité nécessiterait une certaine prévoyance. Mais au moins pandas 2 devrait considérer les noms de fonction comme readr .

Je commence tout juste à utiliser les dataframes pandas provenant de R + tidyverse/readr et la première chose qui m'a négativement impressionné est le manque de méthodes de lecture/écriture cohérentes comme :

read_csv()/write_csv() : fichiers CSV séparés par des virgules
read_tsv()/write_tsv() : fichiers séparés par des tabulations
read_delim()/write_delim() : fichiers délimités généraux
read_fwf()/write_fwf() : fichiers à largeur fixe
read_table()/write_table() : fichiers tabulaires où les colonnes sont séparées par des espaces.
read_log()/write_log() : fichiers journaux Web

En 20 ans de science des données en génomique, je n'ai jamais rencontré de fichier csv, la plupart des données existent au format tsv (ou délimité par des espaces blancs). Devoir spécifier sep et citer l'argument en utilisant df.to_csv() pour écrire un fichier tsv (ou délimité par des espaces blancs) est pour le moins gênant.

Avoir df.read_tsv() df.to_tsv() pour les fichiers délimités par des tabulations et df.read_table() df.to_table() pour les fichiers délimités par des espaces blancs serait très utile pour les personnes venant aux pandas de R.

Depuis pandas 0.24, read_table est désormais obsolète (voir https://github.com/pandas-dev/pandas/issues/21948 / https://github.com/pandas-dev/pandas/pull/ 21954). Depuis que j'utilise read_table comme substitut au manque de read_tsv , j'en reçois maintenant beaucoup :

FutureWarning: read_table is deprecated, use read_csv instead, passing sep='\t'.

Du côté positif, la suppression read_table rend plus simple l'ajout des fonctions read_tsv et to_tsv , bien que la marée tourne contre les fonctions de commodité selon https://github .com/pandas-dev/pandas/issues/18262?