You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that df.to_csv(filename) will automatically save the index (because of the choice of default) while pd.read_csv(filename) will then automatically add its own index (again because of the choice of default). A user relying on simple default behaviors doing multiple reading and writing to an CSV file will end up accumulating indices:
and thus can get tripped by this difference in choice of defaults.
Describe the solution you'd like
I would recommend settling on the same default behavior when both storing and retrieving from CSV, possibly simply not storing the index by default when using to_csv to obtain a symmetric result.
API breaking implications
I assume this might break the current API unless we provide a warning for the ongoing change at least for a couple of versions. After all, API is also not meant to be frozen and never improved just because it is being used.
Describe alternatives you've considered
None, this is just a suggestion.
Additional context
Possibly added above.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
It seems that
df.to_csv(filename)
will automatically save the index (because of the choice of default) whilepd.read_csv(filename)
will then automatically add its own index (again because of the choice of default). A user relying on simple default behaviors doing multiple reading and writing to an CSV file will end up accumulating indices:and thus can get tripped by this difference in choice of defaults.
Describe the solution you'd like
I would recommend settling on the same default behavior when both storing and retrieving from CSV, possibly simply not storing the index by default when using
to_csv
to obtain a symmetric result.API breaking implications
I assume this might break the current API unless we provide a warning for the ongoing change at least for a couple of versions. After all, API is also not meant to be frozen and never improved just because it is being used.
Describe alternatives you've considered
None, this is just a suggestion.
Additional context
Possibly added above.
The text was updated successfully, but these errors were encountered: