Pandas: Запрос DataFrame.to_tsv() для чтения текста с разделителями табуляции

В дополнение к тому, что это просто to_csv(sep='\t') , функция to_tsv должна рассмотреть возможность изменения цитирования по умолчанию, поскольку цитирование менее необходимо для файлов tsv.

API панд уже загроможден избытком редко используемых удобных методов. Я действительно не думаю, что добавление еще одного является хорошей идеей.

Я согласен с @shoyer здесь. Все функциональные возможности позволяют сделать это внутри to_csv , и, учитывая, что у нас уже есть много методов, я думаю, что причина для добавления нового должна быть сильнее, чем возможность предоставить другие значения по умолчанию.

Я закрываю это (у нас слишком много открытых вопросов ..), но обсуждение, безусловно, может быть продолжено, если это необходимо.

+1. Как практикующий врач, я был бы очень признателен to_tab сахара.

Я думаю, что причина для добавления нового должна быть сильнее, чем возможность предоставить другие значения по умолчанию.

Удобство IMO — достойное оправдание (людям свойственно писать много текстовых файлов, поэтому to_csv приходится постоянно дополнять параметрами).

Однако моя главная мотивация — это пренебрежение к формату CSV. Мне больно видеть, как люди все еще используют CSV вместо TSV. Очевидно, что поддержка Excel/базы данных играет свою роль. Но такой проект, как pandas, должен стремиться максимально упростить внедрение лучших практик.

хотя в настоящее время для меня это не является серьезной проблемой, csv ориентирован на представительство США / Содружества и не знает о международном уровне. При всей Pythonic философии принятия UTF и интернационализации, разделение табуляцией должно быть предпочтительнее, чем csv/точка с запятой-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' , pandas способствует преобладанию CSV над TSV и задерживает рост превосходящего формата.

Пожалуйста, извините мое невежество в этом вопросе, но помимо того, что его легче читать как человеку, тогда и только тогда, когда заголовки столбцов имеют примерно те же символы, что и соответствующие им данные, что не всегда так, какие преимущества дает TSV по сравнению с CSV? Честно говоря, любопытно, есть ли разница в производительности между ними, я использую TSV прямо сейчас, но, честно говоря, только потому, что файлы данных, с которыми я работаю, были в этом формате, поэтому я оставил их в том же формате.

какие преимущества дает TSV по сравнению с CSV?

Вкладки @Starkiller4011 являются более естественным разделителем столбцовых данных. Они требуют меньше заключений в кавычки, так как значения редко содержат табуляцию, но часто содержат запятые.

Честно говоря, любопытно, есть ли разница в производительности между двумя

Я ожидаю, что разница в производительности тривиальна. Однако, как и в большинстве вещей в науке о данных, реальный тип производительности, который имеет значение, — это эффективность программиста. И я думаю, что с TSV приятнее работать, чем с CSV.

Не все согласны с тем, что разделение табуляцией лучше, чем csv — я, например, не согласен.

Как программисты Python, мы знаем, что пробелы не всегда сохраняются при различных операциях, таких как копирование и вставка. Тем из нас, кто отвечает на множество вопросов по SO, например, регулярно приходится использовать sep="\s\s+" для разбора текста, который люди выгружают в формате, разделенном пробелами, и мы должны надеяться, что они вставили достаточно пробелов. между столбцами, чтобы это работало. Если бы они использовали запятые, или точки с запятой, или вертикальные черты, или что-то еще, это не было бы проблемой. (И я только что подумал о каратах, которые довольно широко использовались в некоторых областях.)

Если мы хотим добавить псевдоним to_tsv , чтобы сделать некоторых людей счастливее, хорошо. Но давайте не будем делать вид, что у TSV нет собственных головных болей, когда вы с ним работаете, и единственное преимущество, о котором я могу думать, это меньше цитирования.

Я думаю, стоит сделать шаг назад и признать, что такая функция, как to_csv , довольно глупая, решение должно быть более общей функцией to_table , которая требует указания разделителя и которая to_csv — это просто удобная оболочка. R имеет эту функциональность в своей функции write.table() , что имеет больше смысла.

Для справки, я считаю, что и CSV, и TSV приемлемы и хороши в форматах. Их обоих следует поддерживать. @ dsm054 дает некоторые неоспоримые преимущества разделителям без пробелов.

На мой взгляд, более серьезной проблемой является использование расширения .csv без разбора (например, при ссылке на TSV). См. обсуждение на https://github.com/pandas-dev/pandas/pull/14587. Я согласен с @stevekm в том, что to_table должна быть общей функцией, в которой вы должны указать свой разделитель, а to_csv или to_tsv должны ориентироваться на эти стандарты. Для того, чтобы сделать это в обратно совместимом, потребуется предусмотрительность. Но, по крайней мере, pandas 2 должны учитывать имена функций в строках readr .

Я только начинаю использовать фреймы данных pandas, поступающие из R + tidyverse/readr, и первое, что меня отрицательно впечатлило, — это отсутствие согласованных методов чтения/записи, таких как:

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(): файлы веб-журналов

За 20 лет работы с данными в области геномики я ни разу не сталкивался с файлом csv, большинство данных существует в формате tsv (или с разделителями-пробелами). Необходимость указывать sep и аргумент в кавычках с помощью df.to_csv() для записи файла tsv (или файла с разделителями-пробелами) по меньшей мере неудобно.

Наличие df.read_tsv() df.to_tsv() для файлов с разделителями табуляции и df.read_table() df.to_table() для файлов с разделителями пробелами было бы очень полезно для людей, переходящих на pandas из R.

Начиная с pandas 0.24, read_table устарело (см. https://github.com/pandas-dev/pandas/issues/21948/https://github.com/pandas-dev/pandas/pull/ 21954). Поскольку я использовал read_table в качестве замены отсутствия read_tsv , теперь я получаю много:

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

С положительной стороны, удаление read_table делает более простым добавление функций read_tsv и to_tsv , хотя тенденция поворачивается против удобных функций согласно https://github .com/pandas-dev/pandas/issues/18262?