BUG: to_string ignored min_rows=1 and showed max_rows rows (GH#64824) - #67376
Open
Parth1353 wants to merge 1 commit into
Open
BUG: to_string ignored min_rows=1 and showed max_rows rows (GH#64824)#67376Parth1353 wants to merge 1 commit into
Parth1353 wants to merge 1 commit into
Conversation
_truncate_vertically splits the fitted row budget into a head half and a tail half. One row leaves no halves, so it fell through to a branch that reads max_rows -- the value before _adjust_max_rows applied min_rows -- and printed that many rows instead of one. The same branch is reached in a terminal with room for exactly one data row, where max_rows is 0 in terminal mode, so the frame was truncated to nothing. Keep the head row in that case, which is what SeriesFormatter already does for max_rows == 1, leaving the remaining fall-through (a fitted budget of zero or less, from a terminal too short to show anything) as it was.
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
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.
doc/source/whatsnew/v3.1.0.rstfile_truncate_verticallysplits the fitted row budget into a head half and a tail half. Onerow leaves no halves, so it fell through to a branch that reads
max_rows— the valuebefore
_adjust_max_rowsappliedmin_rows— and printed that many rows instead of one.The same branch is reached in a terminal with room for exactly one data row. There
max_rowsis0, soiloc[:0]truncated the frame to nothing and the repr showed nodata at all. Same cause, second symptom.
This dates to GH#36434 (2020), which introduced the derived
max_rows_fitted; this onepath kept reading the raw
max_rows.On the open question in the thread (show only the head, or keep head and tail?):
SeriesFormatteralready special-casesmax_rows == 1and keeps the head, which isexactly the output the report asks for. The two formatters agree for every other
min_rows;1was the only value where they disagreed. This makesDataFramematchSeriesrather than inventing a third behaviour.max_rows_fittedcan be negative — a terminal too short for the header givesheight - auxiliary_rows < 0, and truncation still runs — so the remaining fall-through isload-bearing and is left exactly as it was. Swapping the attribute outright would turn
iloc[:0]intoiloc[:-2].Blast radius: rendering 7 frame shapes (including MultiIndex rows and columns, and
horizontally truncated frames) across every combination of
max_rowsandmin_rowsgives1120 outputs, of which 62 change — every one of them a
min_rows=1case, and none of theother combinations.
Not fixed here, pre-existing and separate:
_repr_html_omits the...separator rowwhenever only one row is shown, because
html.pyinserts it ati == tr_row_numinsiderange(nrows)and head-only truncation makes those equal. It reproduces on main withdisplay.max_rows=1and nomin_rowsat all, so it is independent of this change.