[Python-3000] Workaround for py3k build problem on CJK MacOS X?
hyeshik at gmail.com
Sat Aug 16 14:48:58 CEST 2008
On Sat, Aug 16, 2008 at 4:25 AM, "Martin v. Löwis" <martin at v.loewis.de> 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
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.
More information about the Python-3000