On 7 Oct, 2009, at 22:13, M.-A. Lemburg wrote: > Ronald Oussoren wrote: >> >> On 7 Oct, 2009, at 20:05, M.-A. Lemburg wrote: >>> >>> >>> If we do go for a change, we should use sizeof(wchar_t) >>> as basis for the new default - on all platforms that >>> provide a wchar_t type. >> >> I'd be -1 on that. Sizeof(wchar_t) is 4 on OSX, but all non-Unix >> API's >> that deal with Unicode text use ucs16. > > Is that true for non-Carbon APIs as well ? > > This is what I found on the web (in summary): > > Apple chose to go with UTF-16 at about the same time as Microsoft did > and used sizeof(wchar_t) == 2 for Mac OS. When they moved to Mac OS X, > they switched wchar_t to sizeof(wchar_t) == 4. > Both Carbon and the modern APIs use UTF-16. What I don't quite get in the UTF-16 vs. UTF-32 discussion is why UTF-32 would be useful, because if you want to do generic Unicode processing you have to look at sequences of composed characters (base characters + composing marks) anyway instead of separate code points. Not that I'm a unicode expert in any way... Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3567 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20091007/99fa789a/attachment-0001.bin>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4