Julien Palard <julien+pyt...@palard.fr> added the comment: I reread issue6755, issue12485, issue12499, and issue12568 about the textwrap/char width topic, and went to those conclusions:
- It's a hard topic [1][2], so we may not succeed in a single shot. - The work is already done by wcwidth in the libc, which does not exists on windows and may not exist on MacOS. - The work is already partially done for CJK in the Unicode standard. So I'm OK with adding CJK support to textwrap *as a first step*, which means I'm *not* ok with the CJK parameter to the wrap function, as maybe in the future we'll do more. I'm also not OK with this being not the default, as many code using textwrap do not know in advance if they need CJK, they should not care, it should be done right by default. But having CJK support by default also mean we'll have to fallback silently to a non-unicode textwrap if unicodedata is not available, as Victor said in PR-89 "Python requires optparse to compile modules like unicodedata, optparse imports textwrap which now always requires unicodedata", which may or may not lead to surprising behavior. [1] The unicode standard is not clear about character width (not its role, font dependent), only where it's OK to put the line break. [2] CJK is not enough, there's plenty of other characters of width not equal to one, like combining characters, tabulations, non-printables, Prepended_Concatenation_Mark having a typical width of zero but sometimes 1, U+00AD being tricky, Hangul Jamo medial vowels and final consonants are "conjoining", and so on... this need a huge effort / attention, this if we're going down this hole it means a lot of maintenance / new issues about this or that character being reported with the "wrong" size. ---------- nosy: +mdk _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue24665> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
