Pandas: Anfrage für DataFrame.to_tsv() zum Lesen von tabulatorgetrenntem Text

Abgesehen davon, dass es nur to_csv(sep='\t') ist, sollte eine to_tsv -Funktion in Betracht ziehen, die Standardanführungszeichen zu ändern, da Anführungszeichen für tsv-Dateien weniger notwendig sind.

Die Pandas-API ist bereits mit einem Übermaß an selten verwendeten Convenience-Methoden überladen. Ich glaube wirklich nicht, dass es eine gute Idee ist, eine weitere hinzuzufügen.

Ich stimme hier @shoyer zu. Alle Funktionen sind dafür in to_csv vorhanden, und da wir bereits viele Methoden haben, denke ich, dass der Grund, eine neue hinzuzufügen, stärker sein sollte als die Möglichkeit, andere Standardwerte bereitzustellen.

Ich schließe dies (wir haben zu viele offene Punkte ...), aber die Diskussion kann bei Bedarf sicherlich fortgesetzt werden.

+1. Als Praktizierender würde ich to_tab Zucker sehr schätzen.

Ich denke, der Grund, einen neuen hinzuzufügen, sollte stärker sein als die Möglichkeit, andere Standardeinstellungen bereitzustellen.

IMO Bequemlichkeit ist eine würdige Rechtfertigung (Menschen neigen dazu, viele Textdateien zu schreiben, daher muss to_csv ständig mit Parametern ergänzt werden).

Meine Hauptmotivation ist jedoch eine Verachtung für das CSV-Format. Es schmerzt mich zu sehen, dass Leute immer noch CSV über TSV verwenden. Offensichtlich spielt die Unterstützung von Excel/Datenbanken eine Rolle. Aber ein Projekt wie Pandas sollte danach streben, die besten Praktiken so einfach wie möglich zu implementieren.

Obwohl dies derzeit kein großes Problem für mich ist, ist csv US/Commonwealth-Vertretung ausgerichtet und international ahnungslos. Bei aller pythonischen Philosophie der Akzeptanz von UTF und Internationalisierung muss tabulatorgetrennt CSV / Semikolon-SV vorgezogen werden.

Obwohl ich die von @shoyer geäußerte Meinung verstehen kann, stimme ich @dhimmel zu. Meiner Erfahrung nach ist TSV viel eher ein Standardformat für die Datenanalyse als CSV. Es gibt viele Anwendungsfälle, in denen das TSV-Format erforderlich ist, während ich mit keinem für das CSV-Format vertraut bin ( hier ein paar Beispiele für häufige Verwendungen). TSV hat auch den Vorteil, dass der Rohtext leicht lesbar ist und die von @dhimmel erwähnten Probleme mit Zitaten vermeidet.

Ich bin nur etwas dagegen, to_tsv hinzuzufügen. Nach meiner Erfahrung (in den USA) ist CSV häufiger als TSV (zumindest beim Namen für das Dateiformat), aber nur geringfügig. Die Haupttugend to_tsv ist, dass der Name sofort klar macht, was es tut.

CSV und TSV werden beide gut unterstützt und in der Datenwissenschaft weit verbreitet. CSV ist eher ein veraltetes Format, daher verwenden viele rückwärtsgerichtete Projekte standardmäßig CSV. Ich denke jedoch, dass zukunftsorientierte Projekte standardmäßig TSV verwenden sollten, da dies besser für die Datenwissenschaft ist. Da es in Pandas keine standardmäßige to_text_delimited_file -Ausgabefunktion gibt, ist to_csv de facto die Standardeinstellung. Da es den meisten Benutzern nicht wichtig genug ist, sep='\t' manuell anzugeben, trägt Pandas zur Verbreitung von CSVs gegenüber TSVs bei und verzögert den Aufstieg des überlegenen Formats.

Bitte entschuldigen Sie meine Unwissenheit in dieser Angelegenheit, aber abgesehen davon, dass es für Menschen einfacher zu lesen ist, wenn und nur wenn die Spaltenüberschriften ungefähr die gleichen Zeichen wie die entsprechenden Daten haben, was nicht immer der Fall ist, welche Vorteile bietet TSV gegenüber CSV? Ehrlich gesagt neugierig, ob es einen Leistungsunterschied zwischen den beiden gibt, ich verwende TSV im Moment, aber ehrlich gesagt nur, weil die Datendateien, mit denen ich arbeite, in diesem Format kamen, also habe ich sie im selben Format belassen.

Welche Vorteile bietet TSV gegenüber CSV?

@Starkiller4011 -Tabs sind ein natürlicheres Trennzeichen für spaltenweise Daten. Sie erfordern weniger Anführungszeichen, da Werte selten Tabulatoren, aber häufig Kommas enthalten.

Bin mal gespannt, ob es einen Leistungsunterschied zwischen den beiden gibt

Ich würde erwarten, dass der Leistungsunterschied trivial ist. Wie bei den meisten Dingen in der Datenwissenschaft ist jedoch die eigentliche Art der Leistung, auf die es ankommt, die Effizienz des Programmierers. Und ich denke, mit TSVs lässt es sich besser arbeiten als mit CSVs.

Nicht jeder stimmt zu, dass die Tab-Trennung CSV überlegen ist – ich zum Beispiel nicht.

Als Python-Programmierer wissen wir, dass Leerzeichen bei verschiedenen Vorgängen wie Kopieren und Einfügen nicht immer erhalten bleiben. Diejenigen von uns, die zum Beispiel viele Fragen zu SO beantworten, müssen regelmäßig sep="\s\s+" verwenden, um Text zu parsen, der von Leuten in einem durch Leerzeichen getrennten Format abgelegt wurde, und wir müssen hoffen, dass sie genug Leerzeichen eingefügt haben zwischen den Spalten, damit das funktioniert. Wenn sie Kommas oder Semikolons oder Pipes oder so etwas verwenden würden, wäre dies kein Problem. (Und ich dachte nur an Karat, das früher in einigen Bereichen ziemlich weit verbreitet war.)

Wenn wir einen to_tsv -Alias ​​hinzufügen wollen, um einige Leute glücklicher zu machen, okay. Aber lassen Sie uns nicht so tun, als hätte TSV keine eigenen Kopfschmerzen, wenn Sie damit arbeiten, und der einzige Vorteil, den ich mir vorstellen kann, ist weniger Zitieren.

Ich denke, es lohnt sich, einen Schritt zurückzutreten und zu erkennen, dass eine Funktion wie to_csv irgendwie albern ist, die Lösung sollte eine allgemeinere to_table -Funktion sein, die die Angabe eines Trennzeichens erfordert, und welche to_csv ist nur ein praktischer Wrapper. R hat diese Funktionalität in seiner Funktion write.table() , was sinnvoller ist.

Fürs Protokoll, ich denke sowohl CSV als auch TSV und akzeptable und gute Formate. Sie sollten beide unterstützt werden. @dsm054 zeigt einige überzeugende Vorteile von Trennzeichen ohne Leerzeichen.

Ein größeres Problem ist meiner Meinung nach die wahllose Verwendung der Erweiterung .csv (z. B. wenn auf TSVs verwiesen wird). Siehe Diskussion unter https://github.com/pandas-dev/pandas/pull/14587. Ich stimme @stevekm zu, dass to_table eine generische Funktion sein sollte, bei der Sie Ihr Trennzeichen angeben sollten, während sich to_csv oder to_tsv auf diese Standards konzentrieren sollten. Um dies rückwärtskompatibel zu machen, wäre einiges an Voraussicht erforderlich. Aber zumindest Pandas 2 sollte Funktionsnamen nach dem Vorbild von readr berücksichtigen .

Ich fange gerade an, Pandas-Datenrahmen zu verwenden, die von R + tidyverse/readr stammen, und das erste, was mich negativ beeindruckt hat, ist das Fehlen konsistenter Lese-/Schreibmethoden wie:

read_csv()/write_csv(): Kommagetrennte (CSV) Dateien
read_tsv()/write_tsv(): tabulatorgetrennte Dateien
read_delim()/write_delim(): allgemeine Dateien mit Trennzeichen
read_fwf()/write_fwf(): Dateien mit fester Breite
read_table()/write_table(): tabellarische Dateien, bei denen Spalten durch Leerzeichen getrennt sind.
read_log()/write_log(): Webprotokolldateien

In 20 Jahren Data Science in der Genomik bin ich noch nie auf eine CSV-Datei gestoßen, die meisten Daten liegen im tsv-Format (oder durch Leerzeichen getrennt) vor. Es ist, gelinde gesagt, unbequem, sep angeben zu müssen und das Argument mit df.to_csv() zu zitieren, um eine tsv-Datei (oder eine durch Leerzeichen getrennte Datei) zu schreiben.

df.read_tsv() df.to_tsv() für tabulatorgetrennte Dateien und df.read_table() df.to_table() für durch Leerzeichen getrennte Dateien zu haben, wäre sehr hilfreich für Leute, die von R zu Pandas kommen.

Ab Pandas 0.24 ist read_table jetzt veraltet (siehe https://github.com/pandas-dev/pandas/issues/21948 / https://github.com/pandas-dev/pandas/pull/ 21954). Da ich read_table als Ersatz für das Fehlen von read_tsv verwende, bekomme ich jetzt viele:

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

Auf der positiven Seite macht es das Entfernen read_table einfacher, sowohl read_tsv - als auch to_tsv -Funktionen hinzuzufügen, obwohl sich das Blatt gegen Komfortfunktionen gemäß https://github wendet .com/pandas-dev/pandas/issues/18262?