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@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: http://mail.python.org/mailman/options/python-3000/mal%40egenix.com
_______________________________________________
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
