Specify the columns to read from file

[daschw]

I often have to deal with CSV files that where edited by someone in Excel resulting in something like
test.csv:

datacol1, datacol2, ,
0, 1, , [some annoying comment]

When I try to read such a file (CSV.read("test.csv")) I get

MethodError: Cannot `convert` an object of type WeakRefString{UInt8} to an object of type Missings.Missing
This may have arisen from a call to the constructor Missings.Missing(...),
since type constructors fall back to convert methods.
setindex!(::Array{Missings.Missing,1}, ::WeakRefString{UInt8}, ::Int64) at array.jl:583
streamto! at io.jl:303 [inlined]
macro expansion at DataStreams.jl:547 [inlined]
stream!(::CSV.Source{Base.AbstractIOBuffer{Array{UInt8,1}},Missings.Missing}, ::Type{DataStreams.Data.Field}, ::DataFrames.DataFrameStream{Tuple{Array{Int64,1},Array{Int64,1},Array{Missings.Missing,1},CategoricalArrays.CategoricalArray{String,1,UInt32,String,CategoricalArrays.CategoricalString{UInt32},Union{}}}}, ::DataStreams.Data.Schema{true,Tuple{Int64,Int64,Missings.Missing,CategoricalArrays.CategoricalValue{String,UInt32}}}, ::Int64, ::NTuple{4,Base.#identity}, ::DataStreams.Data.##15#16, ::Array{Any,1}, ::Type{Ref{(:datacol1, :datacol2, Symbol(""), Symbol(""))}}) at DataStreams.jl:614
#stream!#17(::Bool, ::Dict{Int64,Function}, ::Function, ::Array{Any,1}, ::Array{Any,1}, ::Function, ::CSV.Source{Base.AbstractIOBuffer{Array{UInt8,1}},Missings.Missing}, ::Type{DataFrames.DataFrame}) at DataStreams.jl:490
(::DataStreams.Data.#kw##stream!)(::Array{Any,1}, ::DataStreams.Data.#stream!, ::CSV.Source{Base.AbstractIOBuffer{Array{UInt8,1}},Missings.Missing}, ::Type{DataFrames.DataFrame}) at <missing>:0
#read#43(::Bool, ::Dict{Int64,Function}, ::Bool, ::Array{Any,1}, ::Function, ::String, ::Type{T} where T) at Source.jl:312
read(::String) at Source.jl:311
include_string(::String, ::String) at loading.jl:522
eval(::Module, ::Any) at boot.jl:235
(::Atom.##63#66)() at eval.jl:104
withpath(::Atom.##63#66, ::Void) at utils.jl:30
withpath(::Function, ::Void) at eval.jl:38
macro expansion at eval.jl:103 [inlined]
(::Atom.##62#65{Dict{String,Any}})() at task.jl:80

It would be nice to be able to specify the columns to read with a keyword like Pandas' usecols to be able to easily avoid such issues.

[quinnj]

Coming soon; stay tuned.

[Nosferican]

R's readr uses col_types to specify which columns to read and how.
CSV.read(; types::Vector{DataType}) could use Nothing for skipping that column...

[quinnj]

On master, using CSV.File, you can now get this by iterating a File object, like:

f = CSV.File(file)
for row in f
    println("a=$(row.a), b=$(row.b)")
end

This will only parse the a and b columns in the file, skipping the others. Users should note that it's most performant to access columns in sequential order (i.e. it's optimized for the normal case where people just read the whole file), but it's completely valid to access, say, in reverse order if so desired.

[Nosferican]

Would it be able to use that through a keyword argument in CSV.read (e.g., col_types = "ccd_i")?

[nalimilan]

I agree, it sounds like a legitimate request to have a convenient way of getting a DataFrame (or another structure) with only the specified columns.

[quinnj]

Nah, I don't think putting this in the function is the right abstraction. For example, I have a lazy Select transformation object that operates on any Tables.jl table and implements itself the interface. So, a user would be able to do:

df = CSV.File("cool_file.csv") |> select(:a, :b) |> DataFrame

to select just the a and b columns from a csv file and materialize it in a DataFrame and the csv parsing will only read the a and b columns. I wouldn't want users to think this was functionality only for CSV.jl :)

I'll leave this issue open until we decide on what to do w/ things like Select; @piever, @joshday, @andyferris, and myself have been discussing it a bit.

[nalimilan]

Makes sense. Though if we keep the CSV.read convenience function, supporting this via an argument wouldn't be absurd.

[Nosferican]

I like the lazy pipeline, but agree on the convenience if read is still available. The other aspect is that the coltypes interface does not only subset columns, but also gives a simple way to specify the type it should be parsed as (e.g., zipcodes being parsed as Integer instead of String).

[piever]

Definitely the pipeline is appealing (using Tables and the related querying framework) but I agree that it's good to have a keyword argument as a shorthand. I wonder if it can be somehow combined with coltypes. For example CSV.read(fn, select = (:height => Float64, :name => String)) would mean "read only columns height and name, parsing the first as Float64 and the second as String" (just throwing out ideas here - haven't thought deeply about the implications of this design).

[quinnj]

The problem here is that trying to support select as a keyword argument is actually much harder than having it be an external construct. To try to support this internally, we'd have to essentially re-implement the external construct internally, by keeping track of the columns the user selected, while also keeping track of the full file's columns (in case they select out-of-order columns). So while I agree it could be nice to have a keyword argument, it just doesn't seem very practical; that's a lot of extra work for functionality that's already available.

[nalimilan]

When you say "internally", do you mean inside CSV.File or inside CSV.read? I would think it's easy to do for the latter since it's already "external" to the CSV.File main logic.

[quinnj]

Yeah, but then we get this weird inversion of dependencies: we'd have to have CSV.jl depend on some "TableOperations.jl" package that provided select functionality, just so users could call CSV.read(file; select=...) w/ a keyword argument instead of keeping everything composable and separate. That feels pretty icky to me.

[andyferris]

I tend to agree with Jacob here. My philosophy is that composable tools are beneficial for both library writers and users, and this is a great example of that where .csv files are loaded lazily and the columns can be picked later.