Pandas: Solicitação de DataFrame.to_tsv() para leitura de texto delimitado por tabulação

Além de ser apenas to_csv(sep='\t') , uma função to_tsv deve considerar alterar a cotação padrão, já que a cotação é menos necessária para arquivos tsv.

A API do pandas já está cheia de métodos de conveniência raramente usados. Eu realmente não acho que adicionar outro é uma boa ideia.

Concordo com @shoyer aqui. Todas as funcionalidades estão lá para fazer isso dentro de to_csv , e como já temos muitos métodos, acho que a razão para adicionar um novo deve ser mais forte do que poder fornecer outros padrões.

Estou encerrando isso (temos muitas questões em aberto ..), mas a discussão certamente pode continuar se necessário.

+1. Como praticante, eu apreciaria muito o açúcar to_tab .

Acho que a razão para adicionar um novo deve ser mais forte do que poder fornecer outros padrões.

A conveniência da IMO é uma justificativa digna (as pessoas tendem a escrever muitos arquivos de texto, então to_csv precisa ser constantemente complementado com parâmetros).

No entanto, minha principal motivação é o desdém pelo formato CSV. Dói-me ver as pessoas ainda usando CSV sobre TSV. Obviamente, o suporte ao excel/banco de dados tem um papel a desempenhar. Mas um projeto como o pandas deve se esforçar para tornar as melhores práticas as mais fáceis de implementar.

embora isso não seja um grande problema para mim atualmente, csv é centrado na representação dos EUA/Commonwealth e não tem conhecimento internacional. Com toda a filosofia Pythonic de aceitação de UTF e internacionalização, a separação por tabulação deve ser preferida a csv / ponto-e-vírgula-sv.

Embora eu possa entender o sentimento apresentado por @shoyer , concordo com @dhimmel. Pela minha experiência, o TSV é muito mais um formato padrão para análise de dados do que o CSV. Existem muitos casos de uso em que o formato TSV é um requisito, enquanto não estou familiarizado com nenhum para o formato CSV (há alguns exemplos de usos comuns aqui ). O TSV também tem a vantagem de que o texto bruto é facilmente legível e evita os problemas de citação, conforme mencionado por @dhimmel.

Eu sou apenas um pouco contra a adição de to_tsv . Na minha experiência (nos EUA), o CSV é mais comum que o TSV (pelo menos no nome do formato do arquivo), mas apenas um pouco. A principal virtude que to_tsv tem a seu favor é que o nome deixa instantaneamente claro o que ele faz.

CSV e TSV são bem suportados e amplamente utilizados em ciência de dados. O CSV é mais um formato herdado, portanto, muitos projetos voltados para trás são padronizados para CSV. No entanto, acho que projetos focados no futuro devem ser padronizados para TSV, pois é melhor para ciência de dados. Como não há função de saída to_text_delimited_file padrão em pandas, to_csv é o padrão de fato. Como a maioria dos usuários não se importa o suficiente para especificar manualmente sep='\t' , os pandas estão contribuindo para a prevalência de CSVs sobre TSVs e atrasando o surgimento do formato superior.

Por favor, desculpe minha ignorância sobre o assunto, mas além de ser mais fácil de ler como um humano, se e somente se os cabeçalhos das colunas tiverem aproximadamente os mesmos caracteres que seus dados correspondentes, o que nem sempre é o caso, quais vantagens o TSV oferece sobre o CSV? Sinceramente curioso se há uma diferença de desempenho entre os dois, eu uso o TSV agora, mas honestamente apenas porque os arquivos de dados com os quais estou trabalhando vieram nesse formato, então os deixei no mesmo formato.

quais vantagens o TSV oferece sobre o CSV?

As guias @Starkiller4011 são um separador mais natural para dados colunares. Eles exigem menos citações, pois os valores raramente contêm tabulações, mas geralmente contêm vírgulas.

Sinceramente curioso se há uma diferença de desempenho entre os dois

Eu esperaria que a diferença de desempenho fosse trivial. No entanto, como a maioria das coisas na ciência de dados, o tipo real de desempenho que importa é a eficiência do programador. E acho que os TSVs são mais agradáveis ​​de se trabalhar do que os CSVs.

Nem todo mundo concorda que a separação por tabulação é superior ao csv -- eu não, por exemplo.

Como programadores Python, sabemos que o espaço em branco nem sempre é preservado em diferentes operações, como copiar e colar. Aqueles de nós que respondem a muitas perguntas no SO, por exemplo, regularmente precisam usar sep="\s\s+" para analisar o texto que as pessoas despejaram em um formato separado por espaços em branco, e esperamos que eles tenham colocado espaços suficientes entre as colunas para que funcione. Se eles estivessem usando vírgulas, ou ponto e vírgula, ou tubos, ou algo assim, isso não seria um problema. (E eu só pensei em quilates, que costumavam ser amplamente usados ​​em alguns campos.)

Se quisermos adicionar um alias to_tsv para deixar algumas pessoas mais felizes, tudo bem. Mas não vamos fingir que o TSV não tem suas próprias dores de cabeça quando você está trabalhando com ele, e a única vantagem que consigo pensar é menos citações.

Acho que vale a pena dar um passo atrás e reconhecer que uma função como to_csv é meio boba, a solução deveria ser uma função to_table mais genérica que requer um delimitador a ser especificado, e que to_csv é apenas uma embalagem de conveniência. R tem essa funcionalidade em sua função write.table() , o que faz mais sentido.

Para que conste, acho que tanto CSV quanto TSV e formatos aceitáveis ​​e bons. Ambos devem ser apoiados. @dsm054 traz algumas vantagens atraentes para delimitadores sem espaço em branco.

Um problema maior na minha opinião é usar a extensão .csv indiscriminadamente (por exemplo, quando se refere a TSVs). Veja a discussão em https://github.com/pandas-dev/pandas/pull/14587. Concordo com @stevekm que to_table deve ser uma função genérica onde você deve especificar seu delimitador, enquanto to_csv ou to_tsv devem se concentrar nesses padrões. Fazer isso em uma retrocompatibilidade exigiria alguma premeditação. Mas pelo menos o pandas 2 deve considerar nomes de funções ao longo das linhas de readr .

Apenas começando a usar os dataframes do pandas vindos do R + cleanverse/readr e a primeira coisa que me impressionou negativamente é a falta de métodos consistentes de leitura/gravação como:

read_csv()/write_csv(): arquivos separados por vírgula (CSV)
read_tsv()/write_tsv(): arquivos separados por tabulação
read_delim()/write_delim(): arquivos delimitados gerais
read_fwf()/write_fwf(): arquivos de largura fixa
read_table()/write_table(): arquivos tabulares onde as colunas são separadas por espaços em branco.
read_log()/write_log(): arquivos de log da web

Em 20 anos fazendo ciência de dados em genômica, nunca encontrei um arquivo csv, a maioria dos dados existe no formato tsv (ou delimitado por espaços em branco). Ter que especificar o argumento sep e aspas usando df.to_csv() para escrever um arquivo tsv (ou delimitado por espaços em branco) é no mínimo inconveniente.

Ter df.read_tsv() df.to_tsv() para arquivos delimitados por tabulação e df.read_table() df.to_table() para arquivos delimitados por espaços em branco seria muito útil para pessoas que vêm para pandas do R.

A partir do pandas 0.24, read_table agora está obsoleto (consulte https://github.com/pandas-dev/pandas/issues/21948 / https://github.com/pandas-dev/pandas/pull/ 21954). Como estou usando read_table como substituto para a falta de read_tsv , agora estou recebendo muitos:

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

No lado positivo, a remoção de read_table torna mais simples adicionar as funções read_tsv e to_tsv , embora a maré esteja voltando contra as funções de conveniência conforme https://github .com/pandas-dev/pandas/issues/18262?