-
Notifications
You must be signed in to change notification settings - Fork 367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve copy of SubDataFrame and DataFrameRow #1564
Conversation
Thanks. I'd be inclined to use wider types instead, with the idea that it preserves more information and it makes things more "type-stable" in the sense that the type does not depend on the particular row (but of course inference doesn't know the columns types of a Cc: @quinnj |
See discussion at JuliaData/Tables.jl#28. |
@nalimilan Also:
method seems strange given our current approach. Maybe we should deprecate it and only provide support for |
Maybe a The |
OK. With the convert methods the problem is that only |
OK. I guess we should at least support Does this PR need anything more? |
I have added a doc string and it should be good. |
@nalimilan This is a follow up to #1534, and should be merged if the other is merged (I separate it as we have enough of changes there).
What it does:
copy
forSubDataFrame
to ensure that it returns aDataFrame
in the future (this is the same functionality as we have but with a syntax taking into account future changes togetindex
that are currently in deprecation period)copy
forDataFrameRow
Actually the second point is crucial as it is a simple change that is consistent with #1534 logic but shows one important thing. Should returned
NamedTuple
have minimal (narrowest) second parametric argument (type specification). This is what is implemented now.Or it should have a wide type specification consistent with
eltype
ofDataFrame
column.The difference is that either:
NamedTuple
is passed to a function and it might be a bit faster to create (not 100% sure though);NamedTuple
created from a row of a givenDataFrame
will have the same concrete type.I am not fully clear what is better (I have implemented first, but I have the feeling that maybe the second approach is better).