On Sat, Aug 16, 2008 at 4:25 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> What do you think? > > I see another alternative: invoke the Apple converters (assuming they > exist). Then, these encodings would only be available on OS X, but > that might be just sufficient. > > Now, I'm not a CFString expert, but I would hope that the conversion > would only be a few lines of C code which can be reviewed quickly.
I like the idea. Here's a preliminary patch implements the codec: http://people.freebsd.org/~perky/py3k-maccodec.diff (no tests or documentations yet) There're two build problems to be resolved in the patch. First, that makes libpython depends on CoreFoundation framework, we need to put "-framework CoreFoundation" somewhere around LIBS. The next is slightly tough. I added new aliasmbcs() function in `site` module to register a user encoding alias to mac codec like mbcs codec does. The function needs `locale` module which imports `_locale` and `_functools`. But they are not available yet on the starting point of build process. I think we'd better force locale in build process on MacOS for the problem. Like MBCS codec, the Mac codec implementation in the patch doesn't support non-strict error modes and codec error callbacks. And it has another problem in stateful encoders related to multiple candidates with multiple unicode letters -> single Mac codepoint mappings like: U+2222 <-> 0xA768, and also U+2222 U+F87F <-> 0xA498 The problem can't be resolved when we're using CF string interface only. The codec would be appropriate just for secondary use when the main codec isn't available. Hye-Shik _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
