-
-
Notifications
You must be signed in to change notification settings - Fork 15
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
Various minor comments related to the text I noticed #3
Comments
Thank you for pointing out these issues. If you prefer to submit a PR with suggestions, I can review them there as well. |
That is a bit surprising. So this function is not mandatory for table types? I will remove the sentence from the text as you suggested.
I will try to add a sentence explaining the difference.
That is surprising too. I thought that this trait function should always return true for a table type regardless of the implementation details. |
@bkamins do we have concrete examples of infinite tables in Julia currently? Maybe we can add these examples as references in the sentence, and replace "this" by "the" as suggested. |
Updated the examples and removed Tables.jl from the dependencies. |
No. See its docstring:
You can have a table that is an iterator of rows that reads from a stream and returns e.g. a |
I think this is another example of a problem in the documentation that we have a little time ago (I forgot where). The documentation in https://tables.juliadata.org/stable/#Implementing-the-Interface-(i.e.-becoming-a-Tables.jl-source) states that to become a Tables.jl source, you must have IMHO, it will be somewhat problematic to treat those cases in which the object can implement the interface but does not provide information that it indeed implements the interface. Probably we can define something that will return wrong information instead of an error by assuming that an object implements Tables.jl API whereas it does not. My opinion is that we always treat objects that returns |
I agree with @ronisbr, and I feel that something could be done differently. IMHO, it all boils down to this attempt to represent "infinite" and "finite" tables with the same traits. |
I found the discussion here: |
Not only. This is a general issue that a vector of structs is a table and since this could be any struct it is hard to cover this. See:
(i.e. vector of dicts is a table) |
I opened JuliaData/Tables.jl#348 to discuss the issue. |
Hum, isn't this example a good case for my point? For example, since this is a vector of dictionaries, which reports julia> pretty_table([Dict(1=>2), Dict(3=>4)])
┌────────────┐
│ Col. 1 │
├────────────┤
│ Dict(1=>2) │
│ Dict(3=>4) │
└────────────┘ |
Oops, sorry, did not see your comment before posting :) Let's discuss there. |
That behavior is what I called "stricter rule" followed by a package in my post. |
In https://github.com/JuliaEarth/geospatial-data-science-with-julia/blob/main/01-geodata.qmd#L175:
is not 100% accurate.
Tables.istable
can returnfalse
and still the passed object can be a valid table. I would just skip it.Tables.istable
is meant mostly for package developers that know the internals of Tables.jl well.This is a soft comment
In https://github.com/JuliaEarth/geospatial-data-science-with-julia/blob/main/01-geodata.qmd#L168C2-L168C2 I would explain why you use
Symdol
(and above you used strings). Also maybe consider using CategoricalArrays.jl if you feel thatGENDER
is categorical?This is a soft comment
https://github.com/JuliaEarth/geospatial-data-science-with-julia/blob/main/01-geodata.qmd#L199
Is not 100% accurate. You use
"This"
word. And the one you use does not have this property. The point is that in general row-wise representation is for larger than RAM data, but not this specific one you present. Also, often "larger than RAM" data will returnTables.istable
asfalse
, and only at run-time it is checked that data is indeed tabular.The text was updated successfully, but these errors were encountered: