Author terry.reedy
Recipients taleinat, terry.reedy
Date 2018-12-21.05:13:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1545369210.89.0.788709270274.issue35208@psf.upfronthosting.co.za>
In-reply-to
Content
Tal, trying to understand your confused description of what behavior you want to fix required me to experiment and think.  There are at least 2 separate issues: triggering of auto-squeeze and lines reported (regardless of what triggers squeezing).  The following pair of experiments exhibits inconsistency in both respects.

>>> print('a'*3920) # Fills 49 80-char lines, correctly not squeezed.
...
>>> print('a'*3921)  # Wrapped to 50 lines, correctly auto squeezed.
[Squeezed text (50 lines).]  # Correct number when reporting wrapped lines.
>>> print('a'*3921+'\n')  # Ditto, but not auto-squeezed.
...
# Squeeze manually
[Squeezed text (1 line).]  # Different line count -- of output lines.
>>> print('a'*3920+'\na')  # Not initially squeezed, '2 lines'.

From msg331784 it appears that you are more concerned here with auto squeeze triggering than with line count.  Now that I think I know what you are trying to fix, I can review the code change.

I agree to consider the ambiguity between output lines and display lines, and the effect on line count, later.

Part of my thinking with the simple auto-squeeze formula, besides just simplifying the code, it this.  Raymond claimed that squeezing slows down printing.  If measurably true, one way to avoid a slow down would be to use a simple heuristic formula to estimate the number of wrapped lines instead of exactly counting.  This would be a separate issue, if needed.
History
Date User Action Args
2018-12-21 05:13:30terry.reedysetrecipients: + terry.reedy, taleinat
2018-12-21 05:13:30terry.reedysetmessageid: <1545369210.89.0.788709270274.issue35208@psf.upfronthosting.co.za>
2018-12-21 05:13:30terry.reedylinkissue35208 messages
2018-12-21 05:13:28terry.reedycreate