Skip to content

fix deprecation and possible faulty construction of pandas tables #221

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

Merged
merged 3 commits into from
Sep 14, 2022

Conversation

ExpandingMan
Copy link
Contributor

@ExpandingMan ExpandingMan commented Sep 14, 2022

Before this PR pandas tables were being constructed from Tables.DictColumnTable using an unordered dict for the columns. This was leading to deprecation warnings as seen here but more importantly, it could result in the creation of table objects which would have content inconsistent with their schema. I'm actually a bit unsure why this was not breaking far more spectacularly (update: it's because the methods provided by DictColumnTable make the ordering of the dict largely unnecessary, but it would still break if anything ever iterated over the columns in the dict.)

I used the OrderedDict constructor from within Tables for this so as not to have to add OrderedCollections as a dependency.

@@ -102,6 +102,6 @@ function _columns(df, columnnames, columntypes)
# output a table
# TODO: realising columns to vectors could be done lazily with a different table type
schema = Tables.Schema(colnames, coltypes)
coldict = Dict(k=>v for (k,v) in zip(colnames, columns))
coldict = Tables.OrderedDict(k=>v for (k,v) in zip(colnames, columns))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good thanks. It unfortunately uses the non-API Tables.OrderedDict, but then we're already using the non-API constructor for Tables.DictColumnTable so 🤷‍♂️

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's not great but I figured it would be easier on everyone... it's not really an ideal API on the Tables end.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll think about a PR to Tables to give some of its table types public constructors.

@cjdoris cjdoris merged commit 1eee573 into JuliaPy:main Sep 14, 2022
@cjdoris
Copy link
Collaborator

cjdoris commented Sep 14, 2022

Thanks!

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

Successfully merging this pull request may close these issues.

2 participants