Simon Kornblith

This seems right given that `unique` has `isequal` semantics. I wonder whether `unique(da; skipna=true)` would be more discoverable than `levels`, but then we'd have to return a DataArray and not...

Could we do: ``` julia isna(da::DataArray, inds...) = getindex(da.na, inds...) values(da::DataArray, inds...) = getindex(da.data, inds...) ``` Seems like this would be less dangerous, and also more easily adapted to deal...

I see these not as desirable parts of our API, but as stopgap solutions until Julia does a better job of handling union types. We don't have a type inference...

If I'm understanding you correctly, with this change we'd have to give up on passing DataArrays to functions that accept AbstractArrays. This would seem to move our idioms further from...

We could have `DataArray{T}

AFAIK, the reason we teach people to avoid union types in parts of their code not interacting with DataArrays is that they are slow, not that there is anything inherently...

I'm not sure we can fix this, nor am I sure there is a unique solution. `&&` and `||` are not actually functions because they short-circuit, so we can't override...

Since #104, that example throws a DimensionMismatch, and `setindex!` should behave identically to a normal array. Is there more work to be done here?

Libz and GZip both offer buffered reading of compressed files, so if you set the buffer size to be small and don't read more than it, that's all that will...

Sounds good to me. It would also be good if `@data([a])` did conversion to a DataArray, as it does conversion to an Array in Base (but see JuliaLang/julia#3737). I'll see...