-
Notifications
You must be signed in to change notification settings - Fork 368
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
Support for construction from a named tuple? #1573
Comments
Splatting should be OK. You can also do Whether or not constructors should allow this also depends on whether we want to allow this for Tables.jl. Cc: @quinnj |
I don't think Tables.jl would do something like this; technically, |
Yeah, I don't see a pressing need to change this given that there are at least two convenient ways of doing this currently. |
OK, I didn't know that would work. Splatting is pretty tough for new users, but: SO you are saying that julia> t = (a = 4.0, b = 2)
(a = 4.0, b = 2)
julia> using DataFrames
julia> df = DataFrame([t])
1×2 DataFrame
│ Row │ a │ b │
│ │ Float64 │ Int64 │
├─────┼─────────┼───────┤
│ 1 │ 4.0 │ 2 │ seems reasonable enough. Should we make a PR for this in the docs? |
Also, it generalizes well if you want to seed a
We could add something like that to the construction section in http://juliadata.github.io/DataFrames.jl/latest/man/getting_started.html#The-DataFrame-Type-1 ? |
That sounds good to me. |
Why not. Maybe right before the examples showing |
I kind of think this should be directly supported, to me it's odd that using DataFrames
DataFrame((a=2,b=[1,2,3])) fails while using DataFrames
DataFrame(a=2,b=[1,2,3]) is the standard way to make a DataFrame. An internal method which just splats a namedtuple seems appropriate. |
The tricky part of supporting that would be ambiguity with |
For a reference, please note that we have the following difference in the two approaches:
|
I would close this issue for the reasons given in the last two posts. Any objections? |
I think this is related to #1569 but gives a very specific suggestion.
Existing DataFrames seem to play very well with named tuples. FOr example,
What is irritating is that you cannot create the DataFrame directly from the named tuple, and instead need to specify types yourself.
There is a workaround with splatting, which can rely entirely on inference!
So my question is: (1) is there any real flaw in the splatting interface
and (2) would you be interested in a PR that makes this more explicit. That is, it would add in a constructor for named tuples and support
The text was updated successfully, but these errors were encountered: