Since the introduction of the iconv codec there have been numerous bug reports related to the codec and the lack of cross platform support for it (ranging from: the codec doesn't compile and the codec doesn't support standard names for common encodings to core dumps in the linking phase). I'd like to question whether the codec is really ready for prime time yet. Right now it causes people more trouble than it does any good. Some examples: https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=675341 https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=690309 https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=712056 https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=694431 The problem doesn't seem to be related to the code implementation itself, but rather the varying quality of iconv implementations out there. OTOH, without some field testing the codec will never get into shape for prime time, so perhaps it would be better to only enable it via a configure option or make a failure to compile the codec as painless as possible. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Mar 31 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 1 days left EuroPython 2003, Charleroi, Belgium: 85 days left
On Mon, Mar 31, 2003 at 09:42:50AM +0200, M.-A. Lemburg wrote:
Since the introduction of the iconv codec there have been numerous bug reports related to the codec and the lack of cross platform support for it (ranging from: the codec doesn't compile and the codec doesn't support standard names for common encodings to core dumps in the linking phase).
I'd like to question whether the codec is really ready for prime time yet. Right now it causes people more trouble than it does any good.
iconv_codec NG is ready to submit to SF. I think the newer implementation can resolve many of the patch reports. I'll submit it in a few days. If you have a time, you can review my patches before my submission. The patch includes ko, zh_CN, zh_TW codecs, also. A note about another problems on the current iconv_codec: http://fallin.lv/cvs/~checkout~/py-multibytecodec/reports/iconv.1 The multibytecodecs which is in my patch submission queue: http://fallin.lv/distfiles/py-multibytecodec-030331.tar.gz
OTOH, without some field testing the codec will never get into shape for prime time, so perhaps it would be better to only enable it via a configure option or make a failure to compile the codec as painless as possible.
I agree. Hye-Shik =)
Hye-Shik Chang wrote:
On Mon, Mar 31, 2003 at 09:42:50AM +0200, M.-A. Lemburg wrote:
Since the introduction of the iconv codec there have been numerous bug reports related to the codec and the lack of cross platform support for it (ranging from: the codec doesn't compile and the codec doesn't support standard names for common encodings to core dumps in the linking phase).
I'd like to question whether the codec is really ready for prime time yet. Right now it causes people more trouble than it does any good.
iconv_codec NG is ready to submit to SF. I think the newer implementation can resolve many of the patch reports.
Are you sure ? As I mentioned in my mail, most problems seem to be related to the platform's iconv implementation, not so much to the Python one.
I'll submit it in a few days. If you have a time, you can review my patches before my submission.
Sorry, no time for that. I'm heading off to Python UK today.
The patch includes ko, zh_CN, zh_TW codecs, also.
A note about another problems on the current iconv_codec: http://fallin.lv/cvs/~checkout~/py-multibytecodec/reports/iconv.1
The multibytecodecs which is in my patch submission queue: http://fallin.lv/distfiles/py-multibytecodec-030331.tar.gz
OTOH, without some field testing the codec will never get into shape for prime time, so perhaps it would be better to only enable it via a configure option or make a failure to compile the codec as painless as possible.
I agree.
-- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Mar 31 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: one day left EuroPython 2003, Charleroi, Belgium: 85 days left
iconv_codec NG is ready to submit to SF.
Assuming the NG label means this is a completely new implementation, I propose we drop the current iconv implementation immediately and consider the NG version as we would consider any newly contributed module at this point in time (i.e. at most two weeks before the first beta of 2.3 is released). --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum
Assuming the NG label means this is a completely new implementation, I propose we drop the current iconv implementation immediately and consider the NG version as we would consider any newly contributed module at this point in time (i.e. at most two weeks before the first beta of 2.3 is released).
Ok. Given the reported problems with the iconv module, and the prospect of getting a complete rewrite, I'll back out the current code. This is quite sad, IMO, as the code *is* useful for the platforms on which it works, and this *is* the majority of the installations on which it is currently built. Regards, Martin
Assuming the NG label means this is a completely new implementation, I propose we drop the current iconv implementation immediately and consider the NG version as we would consider any newly contributed module at this point in time (i.e. at most two weeks before the first beta of 2.3 is released).
Ok. Given the reported problems with the iconv module, and the prospect of getting a complete rewrite, I'll back out the current code.
This is quite sad, IMO, as the code *is* useful for the platforms on which it works, and this *is* the majority of the installations on which it is currently built.
But given that it's only got a small audience, a 3rd party module would satisfy the need just as well, right? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum
But given that it's only got a small audience, a 3rd party module would satisfy the need just as well, right?
The audience is actually quite large: any call to <unicodestr>.encode could invoke this codec, if Python does not provide a builtin codec. This includes, in particular, all CJK codecs. Together with a platform-specific codec wrapper for Windows and OS X, the need to package Python-specific CJK codecs (with the size and maintenance issues that come with them) might vanish. Regards, Martin
participants (4)
-
Guido van Rossum -
Hye-Shik Chang -
M.-A. Lemburg -
martin＠v.loewis.de