[Python-Dev] _iconv_codec

[Guido van Rossum]

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