Martin v. Löwis <mar...@v.loewis.de> added the comment: I think the WideCharToMultibyte approach is just incorrect.
I'm -1 on using wcswidth, though. We already have unicodedata.east_asian_width, which implements http://unicode.org/reports/tr11/ The outcomes of this function are these: - F: full-width, width 2, compatibility character for a narrow char - H: half-width, width 1, compatibility character for a narrow char - W: wide, width 2 - Na: narrow, width 1 - A: ambiguous; width 2 in Asian context, width 1 in non-Asian context - N: neutral; not used in Asian text, so has no width. Practically, width can be considered as 1 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12568> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
