-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
Add low-level create_dataframe_from_blocks helper function #58197
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
phofl
merged 6 commits into
pandas-dev:main
from
jorisvandenbossche:internals-dataframe-from-blocks
Apr 15, 2024
Merged
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
58289bb
Add low-level create_dataframe_from_blocks helper function
jorisvandenbossche 4a427f7
add tests + type annotations
jorisvandenbossche 7ba8441
try fix mypy
jorisvandenbossche 493e481
Merge remote-tracking branch 'upstream/main' into internals-dataframe…
jorisvandenbossche eb91afc
update test_api.py
jorisvandenbossche 07dbcfb
add note about when you plan to use this
jorisvandenbossche File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,50 @@ | ||
from pandas import DataFrame | ||
from pandas.core.internals.api import _make_block | ||
from pandas.core.internals.managers import BlockManager as _BlockManager | ||
|
||
|
||
def create_dataframe_from_blocks(blocks, index, columns): | ||
""" | ||
Low-level function to create a DataFrame from arrays as they are | ||
representing the block structure of the resulting DataFrame. | ||
|
||
Attention: this is an advanced, low-level function that should only be | ||
used if you know that the below-mentioned assumptions are guaranteed. | ||
If passing data that do not follow those assumptions, subsequent | ||
subsequent operations on the resulting DataFrame might lead to strange | ||
errors. | ||
|
||
Assumptions: | ||
|
||
- The block arrays are either a 2D numpy array or a pandas ExtensionArray | ||
- In case of a numpy array, it is assumed to already be in the expected | ||
shape for Blocks (2D, (cols, rows), i.e. transposed compared to the | ||
DataFrame columns). | ||
phofl marked this conversation as resolved.
Show resolved
Hide resolved
|
||
- All arrays are taken as is (no type inference) and expected to have the | ||
correct size. | ||
- The placement arrays have the correct length (equalling the number of | ||
columns that its equivalent block array represents), and all placement | ||
arrays together form a complete set of 0 to n_columns - 1. | ||
|
||
Parameters | ||
---------- | ||
blocks : list of tuples of (block_array, block_placement) | ||
This should be a list of tuples existing of (block_array, block_placement), | ||
where: | ||
|
||
- block_array is a 2D numpy array or a 1D ExtensionArray, following the | ||
requirements listed above. | ||
- block_placement is a 1D integer numpy array | ||
index : Index | ||
The Index object for the `index` of the resulting DataFrame. | ||
columns : Index | ||
The Index object for the `columns` of the resulting DataFrame. | ||
|
||
Returns | ||
------- | ||
DataFrame | ||
""" | ||
blocks = [_make_block(*block) for block in blocks] | ||
axes = [columns, index] | ||
mgr = _BlockManager(blocks, axes) | ||
return DataFrame._from_mgr(mgr, mgr.axes) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a docstring (module and/or function level) to the effect of "we discourage this for everyone except pyarrow. if you think you have a use case for this, let us know at [...]"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@phofl might also have a use case in dask (I don't know id you already have a better idea now if that would be the case?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah we are working on changing how we shuffle data were this would be helpful (we will get a huge number of small data frames, so overhead is painful), but I agree that we should strengthen this a little bit that makes it clear that end users shouldn't need this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I already added a more generic note "For almost all use cases, you should use the standard pd.DataFrame(..) constructor instead." without naming specific libraries that use this.
What would we gain with a "if you think you have a use case for this, let us know at"? Learning about use cases where people would use this is certainly valuable, but in the end it will be public developer API and so if we would in the future change or remove it, we need to go through normal deprecation processes anyway, I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hopefully we'll never have to revisit this again. But if we do, there is evidence that discussions around a deprecation here would be more painful than elsewhere. It would be helpful to know ahead of such a discussion if anyone else was using it. Moreover, the "let us know" is a chance to try to talk anyone out of using this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added "If you are planning to use this function, let us know by opening an issue at https://github.com/pandas-dev/pandas/issues."