Pandas: タブ区切りのテキストを読み取るためのDataFrame.to_tsv（）の要求

to_csv(sep='\t')であることに加えて、 to_tsv関数は、tsvファイルでは引用符があまり必要ないため、デフォルトの引用符を変更することを検討する必要があります。

pandas APIは、めったに使用されない便利なメソッドで既に雑然としています。 別のものを追加するのは良い考えではないと思います。

ここで@shoyerに同意します。 to_csv内でこれを行うためのすべての機能があり、すでに多くのメソッドがあることを考えると、新しいメソッドを追加する理由は、他のデフォルトを提供できるよりも強力なはずです。

私はこれを締めくくります（未解決の問題が多すぎます..）が、必要に応じて議論を続けることができます。

+1。 開業医として、私はto_tab砂糖を高く評価します。

新しいものを追加する理由は、他のデフォルトを提供できるよりも強力なはずだと思います。

IMOの利便性は正当化する価値があります（人々は多くのテキストファイルを書く傾向があるため、 to_csvは常にパラメーターで補足する必要があります）。

しかし、私の主な動機は、CSV形式を軽蔑することです。 まだTSV経由でCSVを使用している人を見るのは辛いです。 明らかに、Excel /データベースのサポートには果たすべき役割があります。 しかし、パンダのようなプロジェクトは、ベストプラクティスを最も簡単に実装できるように努力する必要があります。

これは現在私にとって大きな問題ではありませんが、 csvは米国/連邦の代表中心であり、国際的には認識されていません。 UTFの受け入れと国際化のすべてのPythonの哲学では、タブ区切りはcsv / semicolon-svよりも優先される必要があります。

@shoyerが提唱した感情は理解できますが、 @ dhimmelには同意します。 私の経験では、TSVはCSVよりもはるかに標準的なデータ分析形式です。 TSV形式が必須である多くのユースケースがありますが、私はCSV形式のいずれにも精通していません（ここに一般的な使用法の例がいくつかあります）。 TSVには、生のテキストが読みやすいという利点もあり、@ dhimmelで言及されている引用の問題を回避できます。

to_tsvを追加することに少しだけ反対しています。 私の経験では（米国では）CSVはTSVよりも一般的です（少なくともファイル形式の名前では）が、ほんのわずかです。 to_tsvの主な利点は、その名前によって、その機能が即座に明確になることです。

CSVとTSVはどちらも十分にサポートされており、データサイエンスで広く使用されています。 CSVはよりレガシーな形式であるため、後方に焦点を当てたプロジェクトの多くはデフォルトでCSVになっています。 ただし、データサイエンスに適しているため、フォワードに焦点を当てたプロジェクトはデフォルトでTSVに設定する必要があると思います。 パンダにはデフォルトのto_text_delimited_file出力関数がないため、 to_csvが事実上のデフォルトです。 ほとんどのユーザーは手動でsep='\t'を指定することを気にしないため、パンダはTSVよりもCSVの普及に貢献し、優れたフォーマットの台頭を遅らせています。

この件についての私の無知を許してください。しかし、人間として読みやすいことは別として、列ヘッダーが対応するデータとほぼ同じ文字である場合に限り、TSVはCSVに対してどのような利点を提供しますか？ 正直なところ、2つの間にパフォーマンスの違いがあるかどうか知りたいのですが、現在TSVを使用していますが、正直なところ、使用しているデータファイルがその形式であるため、同じ形式のままにしました。

TSVはCSVに対してどのような利点を提供しますか？

@ Starkiller4011タブは、列データのより自然な区切り文字です。 値にタブが含まれることはめったにありませんが、コンマが含まれることが多いため、引用符は少なくて済みます。

2つの間にパフォーマンスの違いがあるかどうか正直に興味があります

パフォーマンスの違いは些細なことだと思います。 ただし、データサイエンスのほとんどのものと同様に、重要なパフォーマンスの実際のタイプはプログラマーの効率です。 そして、TSVはCSVよりもうまく機能すると思います。

タブの分離がcsvよりも優れていることに誰もが同意しているわけではありません。たとえば、私はそうは思いません。

Pythonプログラマーとして、コピーや貼り付けなど、さまざまな操作で空白が常に保持されるとは限らないことを私たちは知っています。 たとえば、SOに関する多くの質問に答える私たちの場合、空白で区切られた形式でダンプされたテキストを解析するには、定期的にsep="\s\s+"を使用する必要があり、十分なスペースが確保されていることを期待する必要があります。それが機能するための列の間。 カンマ、セミコロン、パイプなどを使用している場合、これは問題にはなりません。 （そして、私はちょうどいくつかの分野でかなり広く使われていたカラットについて考えました。）

to_tsvエイリアスを追加して、一部の人を幸せにしたい場合は、わかりました。 ただし、TSVを使用しているときに、TSVに独自の頭痛の種がないというふりをしないでください。私が考えることができる唯一の利点は、見積もりが少ないことです。

一歩下がって、 to_csvのような関数はちょっとばかげていることを認識する価値があると思います。解決策は、区切り文字を指定する必要がある、より一般的なto_csv to_table関数である必要があります。 to_csvは、便利なラッパーです。 Rのwrite.table()関数にはこの機能があり、より理にかなっています。

記録としては、CSVとTSVの両方、および許容できる適切な形式だと思います。 両方ともサポートされている必要があります。 @ dsm054は、空白以外の区切り文字にいくつかの魅力的な利点をもたらします。

私の意見では、より大きな問題は、 .csv拡張機能を無差別に使用することです（たとえば、TSVを参照する場合）。 https://github.com/pandas-dev/pandas/pull/14587のディスカッションを参照してください。 to_tableは区切り文字を指定するジェネリック関数であり、 to_csvまたはto_tsvはこれらの標準に焦点を当てる必要があるという@stevekmに同意します。 これについて下位互換性を保つには、ある程度の予見が必要です。 ただし、少なくともpandas 2は、readerの行に沿って関数名を考慮する必要があります。

R + tidyverse / readerからのパンダデータフレームを使い始めたばかりで、私が最初に否定的に感銘を受けたのは、次のような一貫した読み取り/書き込みメソッドがないことです。

read_csv（）/ write_csv（）：コンマ区切り（CSV）ファイル
read_tsv（）/ write_tsv（）：タブ区切りファイル
read_delim（）/ write_delim（）：一般的な区切りファイル
read_fwf（）/ write_fwf（）：固定幅のファイル
read_table（）/ write_table（）：列が空白で区切られている表形式のファイル。
read_log（）/ write_log（）：Webログファイル

ゲノミクスでデータサイエンスを行って20年間、csvファイルに遭遇したことはありません。ほとんどのデータは、tsv（または空白で区切られた）形式で存在します。 tsv（または空白で区切られた）ファイルを作成するためにdf.to_csv（）を使用してsepおよびquoting引数を指定する必要があるのは、控えめに言っても不便です。

タブ区切りファイルの場合はdf.read_tsv（）df.to_tsv（）を、空白区切りファイルの場合はdf.read_table（）df.to_table（）を使用すると、Rからパンダにアクセスする場合に非常に役立ちます。

pandas 0.24以降、 read_tableは非推奨になりました（https://github.com/pandas-dev/pandas/issues/21948 / https://github.com/pandas-dev/pandas/pull/を参照） 21954）。 read_tsvの不足の代わりにread_tableを使用していたので、今では多くのことを取得しています。

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

プラス面として、 read_tableを削除すると、 read_tsv $関数とto_tsv関数の両方を追加するのがより簡単になりますが、 https：// githubのように便利な関数に逆らいます。