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

["Martin v. Löwis"]

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

It's not exactly what I had in mind (although it might be sufficient,
anyway): I thought not of a single codec, but many. They can be
called x-mac-%d, and be implemented with a lookup routine:

def lookup(name):
    if not name.startswith("x_mac_"): return None
    try:
        name = int(name[6:], 10)
    except ValueError:
        return name
    def encode(*args, **kw):
        return codecs.mac_encode(name, *args, **kw)
    def decode(*args, **kw):
        return codecs.mac_decode(name, *args, **kw)
    reader,writer likewise
    return encode,decode,reader,writer

That way, you always have a precise encoding name (this %d name
would be the Apple enumerator value, of course).

This assumes that OSX has always all the Apple codecs installed,
of course. Even if not, it may not be a problem if mac_encode
raises a proper exception if conversion fails.

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

If that is a problem, we could move that codec into a separate module,
right?

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

If you follow my approach, you wouldn't need such an alias.

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

I think these restrictions are fine.

Regards,
Martin

P.S. I don't think you need to make so many global functions.
This code could live completely in _codecsmodule.c, right?
Even if not, use _Py functions if you can - you don't need
to make those support different Py_UNICODE sizes.