Can anybody explain the point of the iconv_codec module to me? I see no docs for it, there's a continued stream of bug reports related to it. I've heard that it's a wrapper around some 3rd party library, but that doesn't help me -- I don't know anything about that 3rd party library module either. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, Feb 24, 2003 at 08:08:13AM -0500, Guido van Rossum wrote:
Can anybody explain the point of the iconv_codec module to me? I see no docs for it, there's a continued stream of bug reports related to it. I've heard that it's a wrapper around some 3rd party library, but that doesn't help me -- I don't know anything about that 3rd party library module either.
--Guido van Rossum (home page: http://www.python.org/~guido/)
_iconv_codec wraps around iconv(3) function which is defined in POSIX. (http://www.opengroup.org/onlinepubs/007904975/functions/iconv.html) IMHO, we don't need docs for it because no user is expected to access _iconv_codec directly. It just provides a codec set interface to libiconv when python doesn't have standard codec for some encoding. I feel that raising RuntimeError on init_iconv_codec is producing numerous bug reports. Because insane iconv(3) is fatal for iconv_codec but not for python, I think it should raise ImportError instead of RuntimeError. To be honest, there're some minor problems on _iconv_codec that I know, currently. I'm working on an unified multibyte codec codebase for {zh,ja,ko,iconv}codecs nowadays. I guess that I can submit fully reimplemented versions of {zh,ko,iconv}codecs in a week. It will resolve most problems on now. Sorry for immature status of _iconv_codec and I will do my best to make it stable before 2.3b1. Thank you. Regards, Hye-Shik =)
_Iconv_codec wraps around iconv(3) function which is defined in POSIX. (http://www.opengroup.org/onlinepubs/007904975/functions/iconv.html)
There are many POSIX standards. Which one is that? The title says "The Open Group Base Specifications Issue 6" which doesn't help me.
IMHO, we don't need docs for it because no user is expected to access _iconv_codec directly. It just provides a codec set interface to libiconv when python doesn't have standard codec for some encoding.
Well, *somebody* is going to have to know how it works, and fix the bugs long after you've lost interested in this project. I don't care if you explain it in the form of comments in the Python or C modules, but there needs to be more explanation of what this is and how it works.
I feel that raising RuntimeError on init_iconv_codec is producing numerous bug reports. Because insane iconv(3) is fatal for iconv_codec but not for python, I think it should raise ImportError instead of RuntimeError.
The right time to test for insane iconv() is at configure time, not at import time. Before I changed your Py_FatalError() calls to raising RuntimeError, there were even more problems. Saying the bug reports are caused by the RuntimeError is not right: the problems are caused by iconv(), not by the specific exception that is being raised.
To be honest, there're some minor problems on _iconv_codec that I know, currently. I'm working on an unified multibyte codec codebase for {zh,ja,ko,iconv}codecs nowadays. I guess that I can submit fully reimplemented versions of {zh,ko,iconv}codecs in a week. It will resolve most problems on now.
Sorry for immature status of _iconv_codec and I will do my best to make it stable before 2.3b1.
OK, keep them patches coming to SF. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (2)
-
Guido van Rossum -
Hye-Shik Chang