> 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/archive%40mail-archive.com
