> _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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4