Andrei Kulakov <andrei....@gmail.com> 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 <rep...@bugs.python.org> <https://bugs.python.org/issue32397> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com