Pandas: Solicitud de DataFrame.to_tsv() para leer texto delimitado por tabuladores

Además de ser solo to_csv(sep='\t') , una función to_tsv debería considerar cambiar las comillas predeterminadas, ya que las comillas son menos necesarias para los archivos tsv.

La API de pandas ya está repleta de un exceso de métodos de conveniencia que rara vez se usan. Realmente no creo que agregar otro sea una buena idea.

Estoy de acuerdo con @shoyer aquí. Toda la funcionalidad está ahí para hacer esto dentro to_csv , y dado que ya tenemos muchos métodos, creo que la razón para agregar uno nuevo debería ser más fuerte que poder proporcionar otros valores predeterminados.

Estoy cerrando esto (tenemos demasiados temas abiertos...), pero la discusión ciertamente puede continuar si es necesario.

+1. Como practicante, apreciaría mucho el azúcar to_tab .

Creo que la razón para agregar uno nuevo debería ser más fuerte que poder proporcionar otros valores predeterminados.

La conveniencia de IMO es una justificación digna (las personas tienden a escribir muchos archivos de texto, por lo que to_csv debe complementarse constantemente con parámetros).

Sin embargo, mi principal motivación es el desdén por el formato CSV. Me duele ver que la gente sigue usando CSV en lugar de TSV. Obviamente, el soporte de Excel/base de datos tiene un papel que desempeñar. Pero un proyecto como pandas debe esforzarse por hacer que las mejores prácticas sean las más fáciles de implementar.

aunque este no es un problema importante para mí actualmente, csv está centrado en la representación de EE. UU./Commonwealth y no tiene conocimiento internacional. Con toda la filosofía Pythonic de aceptación de UTF e internacionalización, se debe preferir la separación por tabulaciones sobre csv / punto y coma-sv.

Si bien puedo entender el sentimiento presentado por @shoyer , estoy de acuerdo con @dhimmel. Según mi experiencia, TSV es mucho más un formato estándar para el análisis de datos que CSV. Hay muchos casos de uso en los que el formato TSV es un requisito, mientras que no estoy familiarizado con ninguno para el formato CSV ( aquí hay un par de ejemplos de usos comunes). TSV también tiene la ventaja de que el texto sin procesar es fácil de leer y evita los problemas con las citas como lo menciona @dhimmel.

Solo me opongo un poco a agregar to_tsv . En mi experiencia (en los EE. UU.), CSV es más común que TSV (al menos en el nombre del formato de archivo), pero solo un poco. La principal virtud que tiene to_tsv es que el nombre deja en claro al instante lo que hace.

CSV y TSV están bien respaldados y se usan ampliamente en la ciencia de datos. CSV es más un formato heredado, por lo que muchos proyectos centrados en versiones anteriores utilizan CSV de forma predeterminada. Sin embargo, creo que los proyectos enfocados en el futuro deberían usar TSV de forma predeterminada, ya que es mejor para la ciencia de datos. Dado que no hay una función de salida to_text_delimited_file predeterminada en pandas, to_csv es la función predeterminada de facto. Dado que a la mayoría de los usuarios no les importa especificar manualmente sep='\t' , pandas está contribuyendo a la prevalencia de los CSV sobre los TSV y retrasando el surgimiento del formato superior.

Disculpe mi ignorancia sobre el tema, pero además de ser más fácil de leer como humano, si y solo si los encabezados de las columnas tienen aproximadamente los mismos caracteres que sus datos correspondientes, lo cual no siempre es el caso, ¿qué ventajas ofrece TSV sobre CSV? Honestamente curioso si hay una diferencia de rendimiento entre los dos, uso TSV en este momento, pero honestamente solo porque los archivos de datos con los que estoy trabajando vienen en ese formato, así que los dejé en el mismo formato.

¿Qué ventajas ofrece TSV sobre CSV?

Las pestañas de @Starkiller4011 son un separador más natural para los datos en columnas. Requieren menos comillas, ya que los valores rara vez contienen tabulaciones, pero a menudo contienen comas.

Honestamente curioso si hay una diferencia de rendimiento entre los dos

Espero que la diferencia de rendimiento sea trivial. Sin embargo, como la mayoría de las cosas en la ciencia de datos, el tipo real de rendimiento que importa es la eficiencia del programador. Y creo que es mejor trabajar con los TSV que con los CSV.

No todos están de acuerdo en que la separación de tabulaciones es superior a csv; yo no, por ejemplo.

Como programadores de Python, sabemos que los espacios en blanco no siempre se conservan en diferentes operaciones, como copiar y pegar. Aquellos de nosotros que respondemos muchas preguntas sobre SO, por ejemplo, regularmente tenemos que usar sep="\s\s+" para analizar el texto que las personas han descargado en un formato separado por espacios en blanco, y tenemos que esperar que hayan puesto suficientes espacios entre columnas para que eso funcione. Si estuvieran usando comas, punto y coma, barras verticales o algo así, esto no sería un problema. (Y solo pensé en los quilates, que solían usarse bastante en algunos campos).

Si queremos agregar un alias to_tsv para hacer más felices a algunas personas, está bien. Pero no pretendamos que TSV no tenga sus propios dolores de cabeza cuando trabajas con él, y la única ventaja en la que puedo pensar es menos citas.

Creo que vale la pena dar un paso atrás y reconocer que una función como to_csv es un poco tonta, la solución debería ser una función to_table más genérica que requiere que se especifique un delimitador, y que to_csv es solo un envoltorio conveniente. R tiene esta funcionalidad en su función write.table() , lo que tiene más sentido.

Para que conste, creo que tanto CSV como TSV son formatos aceptables y buenos. Ambos deben ser apoyados. @dsm054 presenta algunas ventajas convincentes para los delimitadores que no son espacios en blanco.

En mi opinión, un problema mayor es el uso indiscriminado de la extensión .csv (por ejemplo, cuando se hace referencia a TSV). Consulte la discusión en https://github.com/pandas-dev/pandas/pull/14587. Estoy de acuerdo con @stevekm en que to_table debería ser una función genérica en la que debería especificar su delimitador, mientras que to_csv o to_tsv deberían centrarse en esos estándares. Hacer esto en una compatibilidad con versiones anteriores requeriría un poco de previsión. Pero al menos pandas 2 debería considerar nombres de funciones en la línea de readr .

Recién comencé a usar marcos de datos de pandas provenientes de R + tidyverse/readr y lo primero que me impresionó negativamente es la falta de métodos consistentes de lectura/escritura como:

read_csv()/write_csv(): archivos separados por comas (CSV)
read_tsv()/write_tsv(): archivos separados por tabulaciones
read_delim()/write_delim(): archivos generales delimitados
read_fwf()/write_fwf(): archivos de ancho fijo
read_table()/write_table(): archivos tabulares donde las columnas están separadas por espacios en blanco.
read_log()/write_log(): archivos de registro web

En 20 años haciendo ciencia de datos en genómica, nunca encontré un archivo csv, la mayoría de los datos existen en formato tsv (o delimitado por espacios en blanco). Tener que especificar sep y citar el argumento usando df.to_csv() para escribir un archivo tsv (o delimitado por espacios en blanco) es un inconveniente, por decir lo menos.

Tener df.read_tsv() df.to_tsv() para archivos delimitados por tabuladores y df.read_table() df.to_table() para archivos delimitados por espacios en blanco sería muy útil para las personas que llegan a pandas desde R.

A partir de pandas 0.24, read_table ahora está obsoleto (ver https://github.com/pandas-dev/pandas/issues/21948 / https://github.com/pandas-dev/pandas/pull/ 21954). Como he estado usando read_table como sustituto de la falta de read_tsv , ahora obtengo muchos:

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

En el lado positivo, eliminar read_table hace que sea más sencillo agregar las funciones read_tsv y to_tsv , aunque la marea se está volviendo contra las funciones de conveniencia según https://github .com/pandas-dev/pandas/issues/18262?