Jacob Quinn

An alternative strategy that wouldn't require packages with Tables.j dependencies to have compat like `"~1.0"`, would be to only introduce new interface API changes in major release versions, which seems...

Sorry for the slow response: https://github.com/JuliaData/Tables.jl/pull/288

Doing ```julia rows = ((x=rand(), y=rand()) for i = 1:1000) @time columntable(rows) ``` Is pretty efficient; it avoids allocating the individual NamedTuples for the majority of cases because it can...

Fixed via https://github.com/JuliaPy/Pandas.jl/commit/b120a90654d942e2495eb711ed688e66ad1d6789?

Ok, I've been noodling on this for.......6 days (haha, actually longer, because people have brought it up on slack and stuff). @rofinn can you talk a little more about the...

With https://github.com/JuliaData/Tables.jl/pull/131, we're committing to enhancing the Tables.jl interface a bit, but also trying to keep it very minimal, to encourage adoption. As I've thought of this and a few...

Couple of additional thoughts: * I've changed `RowIterator` in this PR to subtype `AbstractVector{ColumnsRow{T}}`, which means that all column tables would "just work" automatically for `Tables.indexablerows` as is defined in...

> implementing the interface is enough @nalimilan, @bkamins, the problem IMO is that I think it's going to be too hard/complex to expect users to correctly implement all the possible...

I guess part of my hesitation there is the "incompleteness" of the full indexing interface; I understand the "basic" indexing interface, but that only allows single `x[i]`. Like, what are...

Ok, jumping back into things here; sorry for the delay; personal life has been a bit crazy lately. > * `getindex` should be implemented not only to access a single...