feat!: Rename cut/qcut struct fields
#10520
Closed
Conversation
This file contains 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
stinodego
requested review from
ritchie46,
alexander-beedie and
orlp
as code owners
github-actions
bot
added
breaking
stinodego
force-pushed
the
cut-qcut-struct-names
branch
from
7e39699
to
0c4a9ce
Compare
stinodego
force-pushed
the
cut-qcut-struct-names
branch
from
0c4a9ce
to
520ef6c
Compare
|
Closing this for now in favor of a more rigorous refactor discussed in #10468 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
If
include_breaks=True, the output ofcut/qcutis a struct. This improves the field names:brk->breakNAME_bin->categoryI believe this change is mild enough to be included without a prior deprecation warning.
Related: the design of these functions breaks our premise of one expression = one data type. The Lazy schema is incorrect too. But this is a separate discussion.