Andrei Kulakov <[email protected]> added the comment:
This issue is due to *drop_whitespace* arg being True by default.
Documentation states that *drop_whitespace* applies after wrapping, so the fix
in the PR would break that promise because, as far as I understand, it applies
the wrapping after *drop_whitespace*. (Irit's comment on the PR refers to this).
I feel like the behaviour in the PR is more logical and probably what most
users would prefer and need in most cases. But it's a backwards compatibility
change of behaviour that's not buggy.
'foo bar'
# wrap for width=10
['foo','bar'] # current behaviour
['foo bar'] # more intuitive wrapping to width=10
As I was looking at this, I thought that wrapping with drop_whitespace=False
would surely be stable. Not so!
It looks like the logic assumes that \n needs to be replaced by a space for
cases like 'foo\nbar', which makes sense because otherwise two words would be
joined together. But with drop_whitespace=False, repeated fill() calls will
keep replacing \n with a space and then adding a new \n to split lines again:
original: 'xxxx xxxx xxxx xxxx xxxx. xxxx'
wrapped: 'xxxx xxxx xxxx xxxx xxxx. \nxxxx'
wrapped twice: 'xxxx xxxx xxxx xxxx xxxx. \nxxxx'
wrapped thrice: 'xxxx xxxx xxxx xxxx xxxx. \nxxxx'
Further, a newline with a nearby space within the requested width will be
converted to two spaces:
'a\n b' => 'a b'
I don't know if the original issue is worth fixing or not, but I think the
issue shown above would be good to fix.
----------
nosy: +andrei.avk
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue32397>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
