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>
Python-bugs-list mailing list

Reply via email to