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 , 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
 The unicode standard is not clear about character width (not its role, font
dependent), only where it's OK to put the line break.
 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.
Python tracker <rep...@bugs.python.org>
Python-bugs-list mailing list