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

[M.-A. Lemburg]

I'm -1 on taking this approach this late in the release process.

You are adding a completely new codec, which hasn't received enough
testing. Furthermore, the concept of relying on OS defined codecs is
not in line with our concept of shipping codecs that work on all
platforms, not just the OS where they happen to be available via
some system libraries (and then completely outside of our control).

For 3.0, please just add aliases to the existing codecs and a
note that this is just a work-around to be able to build Python
on Mac OS X.

For 3.1, we'll then have to add proper codecs for the missing
encodings, hopefully reusing the existing CJK mapping tables.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 17 2008)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

On 2008-08-16 17:30, Martin v. Löwis wrote:
>> 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.
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/mal%40egenix.com