Message 145523 - Python tracker

Message145523

Author	loewis
Recipients	Nicholas.Cole, ezio.melotti, inigoserna, loewis, tchrist, vstinner, zeha
Date	2011-10-14.14:56:58
SpamBayes Score	0.0076282495
Marked as misclassified	No
Message-id	<1318604219.18.0.9022990154.issue12568@psf.upfronthosting.co.za>
In-reply-to

Content
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

Content

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

History
Date	User	Action	Args
2011-10-14 14:56:59	loewis	set	recipients: + loewis, vstinner, ezio.melotti, inigoserna, zeha, Nicholas.Cole, tchrist
2011-10-14 14:56:59	loewis	set	messageid: <1318604219.18.0.9022990154.issue12568@psf.upfronthosting.co.za>
2011-10-14 14:56:58	loewis	link	issue12568 messages
2011-10-14 14:56:58	loewis	create