Skip to content
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 Tables.istable by adding Tables.astable #348

Open
bkamins opened this issue Oct 9, 2023 · 6 comments
Open

Improve Tables.istable by adding Tables.astable #348

bkamins opened this issue Oct 9, 2023 · 6 comments

Comments

@bkamins
Copy link
Member

bkamins commented Oct 9, 2023

@quinnj The issue that Tables.istable can return false and the object is still a table resurfaces often. See e.g. JuliaEarth/geospatial-data-science-with-julia#3 from today.

What I propose:

  1. allow packages to assume that only something for which Tables.istable returns true is a table; (stricter rule)
  2. still other packages can take anything to be a table; (loose rule)

For packages that want to follow the stricter rule it would be nice to add a method to e.g. Tables.table:

Tables.astable(t) = GenericTable(t)

where GenericTable would be a thin wrapper for which Tables.istable would return true, and all other methods would just unwrap t from GenericTable and call it.

In this way packages following stricter rule could easily distinguish between general objects that are not tables and something that user explicitly asked to be a table.

@ronisbr
Copy link
Member

ronisbr commented Oct 9, 2023

I fully agree with the proposal of @bkamins ! I would just change how we call those scenarios.

In my opinion, I would call an object that returns Tables.istable == true something that follows Tables.jl public API and not just a table. Because we can have a table (in the generic sense) that does not completely implement Tables.jl API but can be used as tabular data.

Hence, packages that want to follow the loose rule, can use the Tables.jl functions to fetch the data, even though the object does not comply with the Tables.jl public API. Packages that want to follow the stricter rule, just need to mention that they are expecting something compliant with the Tables.jl public API.

Does it make sense or is it even more complicated?

@ronisbr
Copy link
Member

ronisbr commented Oct 9, 2023

One good example pointed out by @bkamins is the vector of Dict. It does not comply with Tables.jl API. Hence, PrettyTables.jl, which expects it, prints them as a vector:

julia> pretty_table([Dict(1=>2), Dict(3=>4)])
┌────────────┐
│     Col. 1 │
├────────────┤
│ Dict(1=>2) │
│ Dict(3=>4) │
└────────────┘

DataFrames, on the other hand, parse the data as follows:

julia> DataFrame([Dict(1=>2), Dict(3=>4)])
2×8 DataFrame
 Row │ slots                              keys                               vals                               ndel   count  age     idxfloor  maxprobe
     │ Array                             Array                             Array                             Int64  Int64  UInt64  Int64     Int64
─────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1 │ UInt8[0x00, 0x00, 0x00, 0x00, 0x  [0, 4585988768, 5056425184, 4585  [0, 5776188496, 5056425184, 4585      0      1       1        15         0
   2 │ UInt8[0x00, 0x00, 0x00, 0x00, 0x  [0, 4585988768, 5056425184, 4585  [0, 4585988768, 5056425184, 4585      0      1       1        14         0

@bkamins
Copy link
Member Author

bkamins commented Oct 9, 2023

Does it make sense or is it even more complicated?

I think, if we add Tables.astable, we do not even need to use name for the behavior. Packages should just announce that they either:

  • only treat as tables objects that produce true from Tables.istable (and thus require use of Tables.astable for objects that do not fully implement Tables.jl API). PrettyTables.jl is an example of such a package.
  • or assume that anything can be potentially a table, regardless of what Tables.istable returns. DataFrames.jl is such a package (and probably will stay so, because changing this would be breaking)

@ronisbr
Copy link
Member

ronisbr commented Oct 9, 2023

Perfect! I think it will make easier to handle those types internally in PrettyTables.jl since now I need to check for custom table-like types if Tables.istable is false (vectors, matrices, and dictionaries).

@bkamins bkamins changed the title Improve Tables.istable Improve Tables.istable by adding Tables.astable Oct 9, 2023
@ronisbr
Copy link
Member

ronisbr commented Oct 9, 2023

Btw, from PrettyTables.jl side, I think that with @bkamins proposal we will not break depending on how Tables.jl would treat vectors, matrices, and dictionaries after Tables.astable. However, if it breaks, I am fine to release a new major version. There are some breaking changes I would want to implement anyway.

@bkamins
Copy link
Member Author

bkamins commented Oct 9, 2023

There are matrices that are tables, but AFAICT all such types implement Tables.istable, so things should be fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants