[Python-3000] Workaround for py3k build problem on CJK MacOS X?

[Hye-Shik Chang]

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
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