API: deprecate from_csv in favor of read_csv

[jreback]

just too confusion and not consistent

related: #3418, #3171

[ghost]

Diffrent defaults for parse_dates is about all of it from looking at those two issues.
depreaction warning would be fine. removing completely is too harsh IMO
, due to breaking old code.

[jreback]

fair enough

[jreback]

closing in favor of #4916

[jorisvandenbossche]

Reopening this because #4916 is also more general about integrating functionality of the from_dict/records functions inside the DataFrame constructor.

Regarding deprecating from_csv, is this something we still want to do? Or has the ship sailed? (and we keep it as an alias with slightly different defaults indefinitely)

[gfyoung]

I think we should just redefine as an alias to read_csv, with the parameter squeeze=True passed in for Series if being called from there.

[jorisvandenbossche]

I think we should just redefine as an alias to read_csv

What is the advantage of redefining? (I suppose you mean making it use the same defaults and pass everything just through to read_csv ?)
Because that will break people's code. Deprecating of course also takes action of the user, but then they at least have the time to adapt.
We can of course also deprecate the different defaults, but I wonder whether that is then worth the complexity.

[gfyoung]

No, absolutely we would need a deprecation cycle. However, I think that would be consistent with functions that we expose both in the pandas namespace (e.g. .merge) and in the DataFrame namespace for example.

That being said, it's largely a convenience thing and not entirely necessary for us to do (we could just remove it if it's simpler).

[jorisvandenbossche]

However, I think that would be consistent with functions that we expose both in the pandas namespace (e.g. .merge) and in the DataFrame namespace for example.

I think that is a bit a different case, as that actually does something with the frame, while from_csv is a class method. And all other read_ functions have no equivalent class method.

But of course, this will mainly annoy people that use it, so not sure it is worth the trouble. But is from time to time comes up (why it exists, why it has different defaults)

[gfyoung]

But of course, this will mainly annoy people that use

The question is: who uses it though?

[jreback]

We should deprecate (and eventually remove) anything that is not consistent with the APIs that we have. There should be 1 way to do things. @gfyoung can you do this for 0.21.0?

[gfyoung]

@jreback : I would like to squeeze this one in, but I would like to get some feedback on how to proceed with tests. Given that .from_csv differs in some defaults compared to read_csv, the output of replacing .from_csv with .read_csv will change on some tests.

Should we continue testing for the output that we currently get from .from_csv but use a modified version of read_csv in the test to get the same output? Or should we modify the expected output for our tests?

[gfyoung]

These are not unit tests per se but largely roundtrip tests, as you can see from the search:

https://github.com/pandas-dev/pandas/search?l=Python&q=from_csv&type=&utf8=%E2%9C%93

[jreback]

@gfyoung you can just catch the warning around existing tests is fine for now (agree not very many). The warning message should be very clear on how to migrate though.

[gfyoung]

The warning message should be very clear on how to migrate though.

When describing how to migrate, to what level of detail should I provide besides pointing them to the docs that describe the differences with the defaults in from_csv and read_csv ?

[jreback]

i would give them a constructed function that could be copy pasted with the args filled in
we do this for the resample warnings (it’s not hard just a little bit of formatting)
ok with having a fairly instructive warning message

[jorisvandenbossche]

The current docstring already gives the alternative spelling with read_csv (although for the default settings): https://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.from_csv.html, so that would be good to include.