deprecate readcsv and writecsv?

[JeffBezanson]

These functions are already just 1-line aliases, so they're easy to deprecate. Has been discussed before, e.g. in JuliaData/DelimitedFiles.jl#13.

I would also favor removing some features from readdlm --- for example it could support only reading 2-d arrays of numbers of a specified type. But this is a slightly separate issue.

[yuyichao]

I do find it very convenient for quickly reading data in a REPL. readdlm is somewhat more typing in the REPL but also not that a big deal if we really want to remove them....

[StefanKarpinski]

I think the problem with the names {read,write}csv is that they suggest you can read/write the general CSV format – which you cannot. I think that even if we don't entirely remove {read,write}dlm we should severely simplify the interface – any maybe require an element type so that the function doesn't have to do anything fancy and probably doesn't even need you to specify a delimiter for files full of numbers.

[sbromberger]

The argument against doing this is that the existing package, CSV.jl, introduces 14 additional depedencies (direct and indirect). This would be a big problem for those of us seeking to keep our pacakges "light".

[JeffBezanson]

My preferred solution for that is to keep a lightweight readdlm in the "standard library", and also lighten the dependencies of CSV.jl via the ongoing refactoring of DataFrames.

[sbromberger]

@JeffBezanson - is it your idea to keep readdlm pretty much the same as it is now, so that my_new_readcsv() could just call it with specific options (much like readcsv today)?

[JeffBezanson]

Maybe, but I do think there are other issues. For instance, for heterogeneous data it should return a set of column vectors instead of a 2d array, or perhaps not support heterogeneous data. Do you actually want it to keep returning Array{Any,2}s?

[davidanthoff]

@sbromberger Note also that if you play along with the iterable tables interface from TableTraits.jl you automatically get integration with CSVFiles.jl (and ExcelFiles.jl, FeatherFiles.jl, StatFiles.jl and soon ParquetFiles.jl]) without taking any dependency on those packages. You will still pull in some small packages, but a lot less than via CSV.jl. Happy to help with any integration work or explain this (probably better in an issue over your package world), just ping me!