Skip to content

BUG: to_string ignored min_rows=1 and showed max_rows rows (GH#64824) - #67376

Open
Parth1353 wants to merge 1 commit into
pandas-dev:mainfrom
Parth1353:fix-64824-to-string-min-rows-1
Open

BUG: to_string ignored min_rows=1 and showed max_rows rows (GH#64824)#67376
Parth1353 wants to merge 1 commit into
pandas-dev:mainfrom
Parth1353:fix-64824-to-string-min-rows-1

Conversation

@Parth1353

@Parth1353 Parth1353 commented Aug 30, 2026

Copy link
Copy Markdown
Contributor

_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. There
max_rows is 0, so iloc[:0] truncated the frame to nothing and the repr showed no
data at all. Same cause, second symptom.

This dates to GH#36434 (2020), which introduced the derived max_rows_fitted; this one
path kept reading the raw max_rows.

On the open question in the thread (show only the head, or keep head and tail?):
SeriesFormatter already special-cases max_rows == 1 and keeps the head, which is
exactly the output the report asks for. The two formatters agree for every other
min_rows; 1 was the only value where they disagreed. This makes DataFrame match
Series rather than inventing a third behaviour.

max_rows_fitted can be negative — a terminal too short for the header gives
height - auxiliary_rows < 0, and truncation still runs — so the remaining fall-through is
load-bearing and is left exactly as it was. Swapping the attribute outright would turn
iloc[:0] into iloc[:-2].

Blast radius: rendering 7 frame shapes (including MultiIndex rows and columns, and
horizontally truncated frames) across every combination of max_rows and min_rows gives
1120 outputs, of which 62 change — every one of them a min_rows=1 case, and none of the
other combinations.

Not fixed here, pre-existing and separate: _repr_html_ omits the ... separator row
whenever only one row is shown, because html.py inserts it at i == tr_row_num inside
range(nrows) and head-only truncation makes those equal. It reproduces on main with
display.max_rows=1 and no min_rows at all, so it is independent of this change.


_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.
@github-actions github-actions Bot added the Awaiting Review PR in the maintainers' court; exempt from staleness label Aug 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Awaiting Review PR in the maintainers' court; exempt from staleness

Projects

None yet

Development

Successfully merging this pull request may close these issues.

BUG: inconsistent behaviour of min_rows and max_rows in dataframe to_string in pd 3.0.1

1 participant