Comments (8)
and the same for colmetadata(df, col)
and colmetadata(df)
?
CC @nalimilan
from dataapi.jl.
This (and your earlier comment in the PR) raise the following issue (which I initially wanted to avoid to ensure simplicity).
We could add a method metadatadict(obj; style::Union{Symbol, Nothing}=nothing)
that would be required to return an AbstractDictionary
supporting its interface - and ensuring that all functions from this interface are fast. If style
is not passed then all key-value pairs are returned. If style
is passed then key-value pairs are filtered to only expose those whose style matches the style
kwarg.
The reason why I have not added this requirement initially was that I was afraid that package maintainers would find it difficult to correctly implement this custom type and metadatadict
function (AbstractDict
interface is more complex than it seems on a surface and it is not properly documented). But maybe we should go for this and have metadatadict
return nothing
by default so that packages can easily detect that some obj
does not have this method implemented.
The alternative, as you propose, would be to add metadatapairs
function (on which we would need to think in detail how to specify its API, but I think it is doable).
(the same for column-level metadata, but let us leave this discussion for later)
CC @nalimilan
from dataapi.jl.
The reason why I have not added this requirement initially was that I was afraid that package maintainers would find it difficult to correctly implement this custom type and
metadatadict
function (AbstractDict
interface is more complex than it seems on a surface and it is not properly documented). But maybe we should go for this and havemetadatadict
returnnothing
by default so that packages can easily detect that someobj
does not have this method implemented.
It's definitely tempting to have a way of directly interacting with an AbstractDict
type so we don't have to ever implement something that could just fall back to a dictionary. It's also nice to have a fairly clear idea of how an object behaves when trying to write quick code.
On the other hand, I have similar apprehensions about the cost of an increasingly strict interface at this point. I recall some trial and error to get interfaces like AbstractDict
to work when first learning Julia. Perhaps we could have an extra package that provides a handful of useful types that support the dictionary interface that also support features we require for the metadata interface.
from dataapi.jl.
Let us wait for what @nalimilan thinks
from dataapi.jl.
Given that we have metadatakeys
, having metadatapairs
would be kind of logical.
metadatadict
is a more tricky issue. If not all packages implement it, how useful would it be in practice? Would we need a fallback that allocates a new Dict
? But in that case mutating it wouldn't affect the original object.
Perhaps we could have an extra package that provides a handful of useful types that support the dictionary interface that also support features we require for the metadata interface.
What would this provide compared with simply using Dict
(which is what DataFrames.jl does for example)?
from dataapi.jl.
Would we need a fallback that allocates a new Dict?
It could be a dynamic dict being a view, but I agree - as commented above - that it is tricky.
In summary - do we think adding metadatapairs
makes sense now, or we add it at some later point when someone needs it?
from dataapi.jl.
As usual, I'd rather wait until somebody really needs it. ;-)
from dataapi.jl.
I couldn't follow all the discussion in #53, but it would make sense to me to just have metadata(df)
dump all the pairs (rather than a new function). I am currently doing this which is a pain:
julia> Dict(key => metadata(df, key) for key in metadatakeys(df))
Dict{String, Float64} with 2 entries:
"RMSE" => 0.10915
"t₀" => 3.974
from dataapi.jl.
Related Issues (20)
- `Between` should accept more than `Int` and `Symbol` HOT 2
- `metadata` method HOT 70
- isordered HOT 4
- Deprecate `All` HOT 9
- TagBot trigger issue HOT 20
- ellipsis notation for Beetwen HOT 4
- Plan for 1.7 release
- Add flatten to DataAPI.jl HOT 6
- Add `Selector` abstract type for ecosytem compat, and rethink `Between` HOT 8
- Change describe contract HOT 2
- add kwarg to levels to keep missing
- nrow and ncol for undefined values HOT 1
- clarify Between HOT 1
- a few concerns about metadata methods HOT 8
- Confusing `levels` fallback HOT 9
- default to metadata! style=:default HOT 6
- Define `rename` and `rename!` for modifying column names? HOT 3
- Don't define unwrap(x::Any) HOT 7
- rownumber HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dataapi.jl.